G.6 Procedures for employing ICE and Outbound

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The procedures described in the following clauses are applied in addition to the procedures of the UE and P‑CSCF described in other clauses of this specification.

G.6.1 Flow establishment procedures

This procedure is initiated by the UE at network registration time, and allows for the establishment of a flow between a UE and its assigned P‑CSCF. This flow can then be used by the P‑CSCF to allow an initial inbound request to traverse the NAT.

Figure G.7: Flow Establishment Procedures for Outbound

1. UE-A initiates network registration by sending a registration request to its assigned P‑CSCF.

2. Upon receipt of a registration request, the P‑CSCF stores received transport header. This includes information to identify the flow between P‑CSCF and UE.

3. The P‑CSCF then sends the registration request to the assigned S‑CSCF after adding information identifying the serving P‑CSCF to the registration request.

4. The S‑CSCF stores the information identifying the serving P‑CSCF and returns a registration response.

5. Upon receipt of the registration responses from the S‑CSCF, the P‑CSCF forwards the registration response to UE-A using the stored transport address information from the registration request.

6. UE-A sends a Keep-Alive request to its assigned P‑CSCF using the same transport address information (source and destination) which was used for the registration request. This Keep-Alive ensures that a NAT binding exists between UE-A and the P‑CSCF allowing for inbound session requests from the P‑CSCF to UE-A.

7. The P‑CSCF responds with a Keep-Alive response which also reflects the received source transport address information. Inclusion of such information allows UE-A to determine if the NAT has rebooted and assigned a new binding and take appropriate action.

G.6.2 Session establishment procedures

The following procedure illustrates the session establishment procedures when both UEs support the ICE methodology. These procedures apply to both the terminating and originating side of the session regardless of whether the UE is behind a NAT.

In the following figure the STUN element represents both a STUN server and STUN Relay server as a single logical element. It would be equally valid if these functions we represented in separate logical elements. The procedures are unaffected by the grouping. Further, this call flow represents a simplified view to illustrate the NAT traversal procedures only. Other network elements not show may be involved in the session establishment process.

Figure G.8: Session Establishment procedure for NAT Traversal using ICE and Outbound

1. UE-A begins candidate transport address collection by performing a request for a transport address for each media flow from the STUN server.

2. The STUN server reserves one of its transport addresses for each media flow and sends the reserved transport address information back to the UE. The STUN server also reflects the source transport address of the original request for a transport address.

If the UE fails to identify STUN servers it concludes that ICE and Outbound procedures are not supported by the network and defaults to operation using the procedures described in clause G.4.

3-4. UE-A repeats the procedures for requesting a transport address for each RTCP flow. These steps may be executed in parallel with steps 1. – 2. or in series.

5. With its three candidates (locally assigned, server reflected and relay) UE-A forms an offer and forwards to its assigned P‑CSCF. The UE includes the SP cand-type, SP rel-addr and SP rel-port in the candidate attribute as defined in IETF RFC 5245 [45].

6. To ensure subsequent responses to the offer are allowed through the NAT, the P‑CSCF stores the transport address information received in the transport header of the offer.

7. The P‑CSCF forwards the Offer to UE-B using one of the previously established flows.

8-11. UE-B performs the candidate gathering procedures as outlined in steps 1. – 4. above.

12. With its three candidates (locally assigned, server reflected and relay) UE-B forms an answer and forwards to its assigned P‑CSCF.

13. The P‑CSCF for UE-A forwards the Answer to UE-A based on the previously stored transport address information. Media can being to flow at this point using the default transport addresses (recommended to be the STUN Relay provided address).

14. Both UE-A and UE-B perform connectivity tests on each received transport address to determine which of the received transport addresses are actually reachable.

15. After the connectivity tests are concluded UE-A sends an updated SDP Offer indicating the agreed to transport address.

16. The P‑CSCF forwards the Offer according to normal routing procedures.

17. UE-B sends an Answer indicating the agreed to transport address.

18. The P‑CSCF forwards the Answer according to normal routing procedures. Media can begin flowing using the newly identified addresses.

19-21. STUN Relay allocated transport addresses are released by the UE once a more efficient address has been identified and the session updated.

G.6.3 Session release procedures

This procedure is applied to by the UE if the IMS-ALG function is not supported by the network, but the network does support ICE and Outbound procedures. Normal session release procedures are followed with the following exception. If a STUN Relay allocated transport address was used for the session, it shall be released by the UE for which the transport address was allocated.

Figure G.9: Session Release Procedure with STUN Relay Resources

1. UE-A receives a trigger to release the session for which STUN Relay resources were allocated.

2. UE-A sends an indication to the STUN Relay server to release resources allowed for RTP.

3. The STUN Relay server releases the allocated resources and returns a response.

4. UE-A sends an indication to the STUN Relay server to release resources allowed for RTCP.

5. The STUN Relay server releases the allocated resources and returns a response.

G.6.4 Session modification procedures

A session modification can cause the creation, and/or modification, and/or release of media flows.

This procedure is applied to by the UE if the IMS-ALG function is not supported by the network, but the network does support ICE and Outbound procedures. When a new media flow is created the procedure used during session establishment for updating the transport addresses (steps 15-17. of the session establishment procedures) shall be applied.

When an existing media flow is released the procedure for session termination shall be applied for the particular media flow.

When an existing media flow is modified, this may lead to a modification of the media flow directly, or to the establishment of a new media flow and release of the existing one.

G.6.5 Policy and Charging Control procedures

When PCC is to be employed for a session, the P‑CSCF is responsible for providing the PCRF/PCF with IMS media flow information related to the service. If the UE has indicated that the active transport address corresponds to a relayed address, the P‑CSCF shall be responsible for using the additional information provided by the UE to convert the media flows derived from the SDP into flow descriptions which will traverse the Policy and Charging Enforcement Point.

The deployment of STUN relay servers requires that the UE be able to communicate with such servers prior to session establishment. The PCC for the IP‑CAN must be set up to allow communication with the STUN relay server prior to IMS session establishment. This may impact gating control in some IP‑CANs which do not support a default or best effort flow which can be used to communicate with the STUN relay server prior to session establishment.

NOTE 1: Predefined PCC rules can be created to allow the UE to communicate with the STUN relay much in the same way the UE is allowed to communicate with the IMS network for session management.

NOTE 2: Given that a STUN relay is a forwarding server under the direction of the UE, necessary precaution needs to be taken by the operator in how it chooses to craft these rules. It is recommended that such predefined rules only guarantee the minimal amount of bandwidth necessary to accomplish the necessary UE to STUN relay communication. Such an approach helps reduce the resources required to support NAT traversal mechanisms. Finally, such an approach allows the preconfigured rule to be over-ridden by dynamic rules which allow for the necessary bandwidth needed by the session.

NOTE 3: The dynamic PCC rule will need to differentiate between different media traffic between UE and STUN relay (e.g. voice vs. video), which can be identified by the different ports assigned by the residential NAT. Session bindings need to take into account that the relevant Terminal IP address may be contained within the ICE candidates contained in the session description, rather than in the normal media description.

G.6.6 Detection of NAT Traversal support

The UE shall be able to determine whether the IMS CN supports the Outbound procedures by the capabilities indicated in the registration response to the UE. If the indication of the capability is present, the UE knows that the IMS CN supports Outbound and the associated procedures.

NOTE: A configuration mechanism can be used to provision STUN server and STUN relay server addresses in the UE.

G.6.7 Procedures at other IMS entities processing SDP

IMS entities processing SDP, such as the P‑CSCF, IBCF or MRFs, may or may not be updated to understand the "candidate alternative addresses" that are part of the ICE procedures, IETF RFC 5245 [45]. IMS entities processing SDP that do not understand the ICE procedures will, in accordance with there compatibility procedures, ignore the "alternative addresses", and media entities, such as the IMS Access Gateway, PCEF, MRFP and TrGW, controlled by the IMS entities processing SDP will not pass connectivity check requests and media on those addresses. IMS entities processing SDP which behave as B2BUAs may or may not pass on the alternative address in accordance with their own compatibility procedures.

Annex H (informative):
Example HSS deployment

This clause describes possible deployment scenarios for the HSS when it operates as an IMS only database.

The following depicts the HSS functionality as described in TS 23.002 [1] repeated here for clarity; note that the functional description in TS 23.002 [1] shall always be considered as the most updated version, if it is different than the version shown here. 3GPP HSS contains functions also known as HLR and AuC, which are needed for 3GPP GPRS and CS domain access authentication and authorization and overall subscription handling as well as service data management.

Figure H.1: HSS functional decomposition

In cases where the HSS would operate as an IMS only entity, the functions and interfaces specific to IMS operations would be applicable. These include support of functionalities such as identification handling, service provisioning support, call/session establishment support, application services support, IMS access authentication and authorization provided by the interfaces Cx, Sh and Si (if applicable to interwork with CAMEL) and any additional subscription and configuration handling for IMS users. This type of configuration of the HSS would be used for access to the IMS as defined by, for example, TISPAN NGN.

Annex I (normative):
Border Control Functions