Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  16.6.0

Top   Top   Up   Prev   Next
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…

 

5.7.5  (AS-T#1) PSI based Application Server termination - direct |R6|Word‑p. 136
This clause depicts a routing example for incoming session where the session request is routed directly to the AS hosting the PSI.
(not reproduced yet)
Figure 5.19d: Incoming session, direct route towards the AS
Up
Step 1.
I-CSCF receives a request destined to the PSI.
Step 2-3.
I-CSCF queries the HSS in order to determine the next hop in the routing path for the PSI.
Step 4.
HSS determines the routing information, i.e., the address of the AS hosting the PSI.
Step 5.
HSS returns the AS address to the I-CSCF.
Step 6-7.
I-CSCF forwards the request to the address received from the query.
Step 8-9.
Session setup continues as per existing procedures.

5.7.6  (AS-T#2) PSI based Application Server termination - indirect |R6|

This clause depicts an example routing scenario where the basic IMS routing via S-CSCF is used to route the session.
(not reproduced yet)
Figure 5.19e: Incoming session, indirect route to AS via S-CSCF
Up
Step 1.
I-CSCF receives a request destined to the PSI.
Step 2-3.
I-CSCF queries HSS in order to determine the next hop in the routing path for the PSI.
Step 4.
HSS determines the routing information, which is the S-CSCF defined for the "PSI user".
Step 5.
HSS returns the S-CSCF address/capabilities to the I-CSCF.
Step 6-7.
I-CSCF, as per existing procedures, forwards the request towards the entity (i.e., S-CSCF) received from the query, or the I-CSCF selects a new S-CSCF if required.
Step 8.
S-CSCF evaluates the filter criteria and gets the AS address where to forward the request.
Step 9.
The request is then routed towards the AS identified by the filter criteria.
Step 10-12.
Session setup continues as per existing procedures.
Up

5.7.7  (AS-T#3) PSI based Application Server termination - DNS routing |R6|Word‑p. 137
This clause shows an example of DNS based routing of an incoming session from an external network. The routing from the external network leads to the entry point of the IMS subsystem hosting the subdomain of the PSI.
(not reproduced yet)
Figure 5.19f: Incoming session, direct route to AS using DNS
Up
Step 1.
I-CSCF receives a request that is destined to the PSI.
Step 2.
I-CSCF has been configured with the list of supported domains/network names, or it may have been configured to directly query a local DNS server.
Step 3.
In this case the I-CSCF checks the list and finds a match.
Step 4.
I-CSCF sends DNS query to find the route.
Step 5.
DNS server returns the IP address of the AS hosting the PSI.
Step 6-7.
I-CSCF forwards the request towards the IP address received from the query.
Step 8-9.
Session setup continues as per existing procedures.

5.7.8  (AST#4) Termination at Application Server based on service logic |R6|Word‑p. 138
This termination procedure applies to an Application Server that terminates a session. In this case the addressed user is a UE and is not hosted by the AS. Based on the invoked service logic at the Application Server the session is terminated at the AS.
The procedure described below assumes that the Application Server takes care of the user plane connection.
(not reproduced yet)
Figure 5.19g: Application Server termination
Up
Step 1.
I-CSCF receives a request destined to the user.
Step 2-3.
I-CSCF queries HSS in order to determine the next hop in the routing path for the user.
Step 4.
HSS determines the routing information, which is the S-CSCF defined for the user.
Step 5.
HSS returns the S-CSCF address/capabilities to the I-CSCF.
Step 6-7.
I-CSCF, as per existing procedures, forwards the request to S-CSCF that will handle the session termination.
Step 8.
S-CSCF evaluates the filter criteria and gets the AS address where to forward the request.
Step 9.
The request is then routed towards the AS identified by the filter criteria. The AS terminates the session instead of allowing it to continue on to the address end user.
Step 10-12.
Session setup continues as per existing procedures.
Up

5.7a  Procedures for the establishment of sessions without preconditions |R6|Word‑p. 139

5.7a.1  General

These clauses present the general end-to-end session flow procedures without preconditions. The flow in clause 5.7a.2 is applicable to services without real-time QoS requirements before session becomes active, and thus do not need to set-up dedicated IP-CAN bearers but can use existing IP-CAN bearers, and to services which do not require that the terminating endpoint obtains a SIP-level notification when the originating endpoint's IP-CAN bearer becomes available.
Note that the flows in these clauses do not show the use of a THIG. If a THIG is used, the use is completely analogous to the use in clause 5.5, clause 5.6 and clause 5.7.
Up

5.7a.2  Procedures for the establishment of sessions without preconditions - no resource reservation required before session becomes activeWord‑p. 141
(not reproduced yet)
Figure 5.19h: End-to-end session flow procedure without preconditions - no resource reservation required before session becomes active
Up
Step 1.
UE#1 sends the SIP INVITE request, containing an initial SDP, to the P-CSCF#1 determined via the P-CSCF discovery mechanism. The initial SDP may represent one or more media for a multi-media session. It should be noted that a media offer without preconditions in general implies that the offering entity might expect to receive incoming media for any of the offered media as soon as the offer is received by the other endpoint. Therefore either an existing IP-CAN bearer is assumed to be available for use or the application is implemented such that incoming media is not expected until some later point in time.
Step 2.
P-CSCF#1 examines the media parameters. If P-CSCF#1 finds media parameters not allowed to be used within an IMS session (based on P-CSCF local policies, or if available bandwidth authorization limitation information coming from the PCRF/PCF), it rejects the session initiation attempt.
Step 3.
P-CSCF#1 forwards the INVITE request to S-CSCF#1 along the path determined upon UE#1's most recent registration procedure.
Step 4.
Based on operator policy S-CSCF#1 validates the user's service profile and may invoke whatever service control logic is appropriate for this INVITE request. This may include routing the INVITE request to an Application Server, which processes the request further on.
Step 5.
S-CSCF#1 forwards INVITE request to I-CSCF#2.
Step 6.
I-CSCF#2 performs Location Query procedure with the HSS to acquire the S-CSCF address of the destination user (S-CSCF#2).
Step 7.
I-CSCF#2 forwards the INVITE request to S-CSCF#2.
Step 8.
Based on operator policy S-CSCF#2 validates the user's service profile and may invoke whatever service control logic is appropriate for this INVITE request. This may include routing the INVITE request to an Application Server, which processes the request further on.
Step 9.
S-CSCF#2 forwards the INVITE request to P-CSCF#2 along the path determined upon UE#2's most recent registration procedure.
Step 10.
P-CSCF#2 examines the media parameters. If P-CSCF#2 finds media parameters not allowed to be used within an IMS session (based on P-CSCF local policies, or if available bandwidth authorization limitation information coming from the PCRF/PCF), it rejects the session initiation attempt.
Step 11.
P-CSCF#2 forwards the INVITE request to UE#2.
Step 12. - 17.
UE#2 may optionally generate a ringing message towards UE#1.
Step 18.
Depending on the bearer establishment mode selected for the IP-CAN session, resource reservation shall be initiated either by the UE or by the IP-CAN itself. UE#2 may reserve a dedicated IP-CAN bearer for media based on the media parameters received in the SDP offer as shown in Figure 5.19h. Otherwise, the IP-CAN#2 initiates the reservation of required resources after step 20 instead.
Step 19.
UE#2 accepts the session with a 200 OK response. The 200 OK response is sent to P-CSCF#2.
Step 20.
Based on operator policy P-CSCF#2 may instruct PCRF/PCF to authorize the resources necessary for this session.
Step 21. - 24.
The 200 OK response traverses back to UE#1.
Step 25.
Based on operator policy P-CSCF#1 may instruct the PCRF/PCF to authorize the resources necessary for this session.
Step 26.
P-CSCF#1 forwards the 200 OK response to UE#1.
Step 27. - 31.
UE#1 acknowledges the 200 OK with an ACK, which traverses back to UE#2.
Step 32.
Depending on the bearer establishment mode selected for the IP-CAN session, resource reservation shall be initiated either by the UE or by the IP-CAN itself. UE#1 may reserve a dedicated IP-CAN bearer for media based on the media parameters received in the SDP answer as shown in Figure 5.19h. Otherwise, the IP-CAN#1 initiates the reservation of required resources after step 25.
Up

5.7a.3Void


Up   Top   ToC