4.6 Roles of Session Control Functions

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

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

4.6.0 General

The CSCF may take on various roles as used in the IP multimedia subsystem. The following clauses describe these various roles.

4.6.1 Proxy‑CSCF

The Proxy‑CSCF (P‑CSCF) is the first contact point within the IM CN subsystem. Its address is discovered by UEs using the mechanism described in the clause "Procedures related to Local CSCF Discovery". The P‑CSCF behaves like a Proxy (as defined in IETF RFC 3261 [12] or subsequent versions), i.e. it accepts requests and services them internally or forwards them on. The P‑CSCF shall not modify the Request URI in the SIP INVITE message. The P‑CSCF may behave as a User Agent (as defined in the IETF RFC 3261 [12] or subsequent versions), i.e. in abnormal conditions it may terminate and independently generate SIP transactions.

NOTE 1: When requests are sent towards another domain they may, if required, be routed via a local network exit point (IBCF), which will then forward the request to the entry point of the other domain. More details on this can be found in clause 4.14 and Annex I.

The P-CSCF in the role of an AF may interact with the Policy and Charging Architecture; the P-CSCF may interact over the Rx interface (see TS 29.214 [11]) with the Policy and Charging Architecture defined in TS 23.203 [54]; the P-CSCF may interact over the Rx interface (see TS 29.214 [11]) or over the N5 interface (using the Npcf_PolicyAutorization service, see TS 29.514 [96]) with the Policy and Charging Architecture defined in TS 23.503 [95].

The functions performed by the P‑CSCF are:

– Forward the SIP register request received from the UE to an entry point determined using the home domain name, as provided by the UE.

– Forward SIP messages received from the UE to the SIP server (e.g. S‑CSCF) whose name the P‑CSCF has received as a result of the registration procedure.

– Ensure that the SIP messages received from the UE to the SIP server (e.g. S‑CSCF) contain the correct or up to date information about the access network type currently used by the UE, when the information is available from the access network. Depending on operator policies, the P‑CSCF may insert in any SIP message (request or response) the access network type currently used by the UE, when the information is available from the access network.

NOTE 2: For the 3GPP access network, the P‑CSCF can derive information about the access network type currently used by the UE using PCC mechanisms as specified in TS 23.203 [54] and in TS 29.214 [11], or in TS 23.503 [95] and in TS 29.514 [96].

NOTE 3: IMS entities other than P‑CSCF will not be informed by this mechanism of the change in the access network unless SIP messages are exchanged.

– Based on operator policies, and the availability of the user location information and/or UE Time Zone from the access network, ensure that relevant SIP messages contain the correct or up to date information about the user location information, and/or UE Time Zone provided by the access network currently used by the UE.

NOTE 4: For the 3GPP access networks and for TWAN access (as defined in clause 16 of TS 23.402 [82]), the P‑CSCF can retrieve user location information and/or UE Time Zone related to the access network currently used by the UE using PCC mechanisms, as specified in TS 23.203 [54] and in TS 29.214 [11], or in TS 23.503 [95] and in TS 29.514 [96].

– Forward the SIP request or response to the UE.

Detect and handle an emergency session establishment request.

– Generation of CDRs.

– Maintain a Security Association between itself and each UE, as defined in TS 33.203 [19].

– Should perform SIP message compression/decompression.

– Authorization of bearer resources and QoS management. For details see TS 23.203 [54] and TS 23.503 [95].

– Detection and handling of an originating or terminating IMS MPS session establishment or session modification request (see also clause 5.21).

– May support the Paging Policy Differentiation for IMS conversational voice as described in clause E.9 and clause Y.9.

– May subscribe to notification of changes in the type of access network using PCC mechanisms as specified in TS 23.203 [54] and in TS 29.214 [11] or in TS 23.503 [95] and in TS 29.514 [96].

4.6.2 Interrogating‑CSCF

4.6.2.0 General

Interrogating‑CSCF (I‑CSCF) is the contact point within an operator’s network for all connections destined to a user of that network operator, or a roaming user currently located within that network operator’s service area.

NOTE- 1: If border control concepts are applied, the contact point within an operator’s network may be different, see clause 4.14 and Annex I for details.

NOTE 2: When requests are sent towards another domain they may, if required, be routed via a local network exit point (IBCF), which will then forward the request to the entry point of the other domain. More details on this can be found in clause 4.14 and Annex I.

There may be multiple I‑CSCFs within an operator’s network. The functions performed by the I‑CSCF are:

Registration

– Assigning a S‑CSCF to a user performing SIP registration (see the clause on Procedures related to Serving‑CSCF assignment)

Session-related and session-unrelated flows

– Route a SIP request received from another network towards the S‑CSCF.

– Translate the E.164 address contained in all Request‑URIs having the SIP URI with user=phone parameter format into the Tel: URI format of IETF RFC 3966 [15] before performing the HSS Location Query. In the event the user does not exist, and if configured by operator policy, the I‑CSCF may invoke the portion of the transit functionality that translates the E.164 address contained in the Request‑URI of the Tel: URI format to a routable SIP URI.

– Obtain from HSS the Address of the S‑CSCF.

– Forward the SIP request or response to the S‑CSCF determined by the step above

Based on local configuration, the I‑CSCF may perform transit routing functions (see clause 5.19). If the I‑CSCF determines, based on an HSS query, that the destination of the session is not within the IMS, it may forward the request or it may return with a failure response toward the originating endpoint.

Charging and resource utilisation:

– Generation of CDRs.

4.6.2.1 Void

4.6.3 Serving‑CSCF

The Serving‑CSCF (S‑CSCF) performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services. Within an operator’s network, different S‑CSCFs may have different functionalities. The functions performed by the S‑CSCF during a session are:

For Registration:

– May behave as a Registrar as defined in IETF RFC 3261 [12] or subsequent versions, i.e. it accepts registration requests and makes its information available through the location server (e.g. HSS).

– When a registration request includes an Instance ID with the contact being registered and indicates support for GRUU, the S‑CSCF shall assign a unique P‑GRUU and a new and unique T‑GRUU to the combination of Public User Identity and Instance ID.

– If a registration request indicates support for GRUU, the S‑CSCF shall return the GRUU set assigned to each currently registered Instance ID.

– The S‑CSCF shall notify subscribers about registration changes, including the GRUU sets assigned to registered instances.

– During registration process, the S-CSCF shall provide policy information, if available, for a Public User Identity from the HSS to the P-CSCF and/or UE.

NOTE 1: For example, the policy information includes MPS IMS Subscription status and policy applicable to enterprise network subscribers.

For Session-related and session-unrelated flows:

– Session control for the registered endpoint’s sessions. It shall reject IMS communication to/from Public User Identity(s) that are barred for IMS communications after completion of registration, as described in clause 5.2.1.

– May behave as a Proxy Server as defined in IETF RFC 3261 [12] or subsequent versions, i.e. it accepts requests and services them internally or forwards them on, possibly after translation.

– May behave as a User Agent as defined in IETF RFC 3261 [12] or subsequent versions, i.e. it may terminate and independently generate SIP transactions.

– Based on the determined served user, handle interaction with Services Platforms for the support of Services

– Provide endpoints with service event related information (e.g. notification of tones/announcement together with location of additional media resources, billing notification)

– For an originating endpoint (i.e. the originating user/UE, or originating AS)

– Obtain from a database the Address of the entry point for the network operator serving the destination user from the destination name (e.g. dialled phone number or SIP URI), when the destination user is a customer of a different network operator, and forward the SIP request or response to that entry point.

If a GRUU is received as the contact, ensures that the Public User Identity of the served user in the request and the Public User Identity encapsulated in the P‑GRUU or associated with the T‑GRUU belongs to the same service profile.

– When the destination name of the destination user (e.g. dialled phone number or SIP URI), and the originating user is a customer of the same network operator, forward the SIP request or response to an I‑CSCF within the operator’s network.

– Depending on operator policy, forward the SIP request or response to another SIP server located within an ISP domain outside of the IM CN subsystem.

– Forward the SIP request or response to a BGCF for call routing to the PSTN or CS Domain.

– Ensure the originating end point is subscribed to the determined IMS communication service.

– Ensure that the content of the SIP request or response (e.g. value included in Content-Type SIP header, media lines included in SDP) sent or received by the originating endpoint matches the determined IMS communication service definition, based on originating user’s subscription.

– When the INVITE message includes an MPS code or an MPS input string, forward the INVITE, including the Service User’s priority level if available.

– When an MPS user is authorized by an AS for priority service, include the Service User’s priority level received from the AS in the INVITE and forward the INVITE.

NOTE 2: The mechanism to provide authorisation by an AS for priority service is out of scope of this specification.

– Attestation of the identity of the originating subscriber if configured through operator policies. Optionally the S-CSCF can invoke an AS for attestation of the identity of originating subscriber, if configured through operator policies.

NOTE 3: Only one network element performs attestation for an originating subscriber in the originating network.

– Assertion of authorization for the Resource-Priority information for an IMS priority session if configured through operator policies. Optionally, the S-CSCF can invoke an AS for assertion and signing of the authorization for the Resource-Priority information for the IMS priority session, if configured through operator policies.

– If the request is an originating request from an Application Server:

– Verify that the request coming from the AS is an originating request, determine the served user and apply procedures accordingly (e.g. invoke interaction with Service Platforms for originating services, etc.).

– Process and proceed with the request even if the served user on whose behalf the AS had generated the request is unregistered. If the served user is unregistered, the S‑CSCF shall execute any unregistered origination service logic on behalf of the served user before forwarding requests from an AS.

– Process and proceed with other requests to and from the served user on whose behalf the AS had generated the request.

– Reflect in the charging information that an AS has initiated the session on behalf of a served user.

– For a destination endpoint (i.e. the terminating user/UE)

– Forward the SIP request or response to a P‑CSCF.

– Modify the SIP request for routing an incoming session to CS domain according to HSS and service control interactions, if the user is to receive the incoming session via the CS domain.

– Forward the SIP request or response to a BGCF for call routing to the PSTN or the CS domain.

– Ensure the terminating end point is subscribed to the determined IMS communication service.

– Ensure that the content of SIP request or response (e.g. value included in Content-Type SIP header, media lines included in SDP) sent or received by the destination end point matches the determined IMS communication service definition, based on terminating user’s subscription.

– If the SIP request contains preferences for characteristics of the destination endpoint, perform preference and capability matching as specified in IETF RFC 3312 [41].

– Optionally for a redirected session, if configured through operator policies, performs attestation of the identity of the diverting subscriber initiating the diversion.

– Proxies a terminating request to an AS associated with the terminating user for signature verification if signature verification is required.

NOTE 4: The S-CSCF would normally proxy any terminating request to an AS via ISC for additional processing.

– For an originating request with a Request URI containing the SIP representation of an E.164 number, and configured per operator policy:

– the S‑CSCF attempts translation of the E.164 address in the SIP URI to a globally routable SIP URI using the procedures specified in clause 4.3.5. As stated in clause 4.3.5, if the E.164 address translation fails, the request may be forwarded to a BGCF to allow routing to the PSTN and if the translation succeeds, the Request URI is updated and the request is routed based on the SIP URI that was obtained.

NOTE 5: When requests are sent towards another domain they may, if required, be routed via a local network exit point (IBCF), which will then forward the request to the entry point of the other domain. More details on this can be found in clause 4.14 and Annex I.

Based on local configuration, the S‑CSCF may be provisioned as the contact point within an operator’s network for transit IMS scenarios and may perform transit routing functions (see clause 5.19).

Charging and resource utilisation:

– Generation of CDRs

4.6.4 Breakout Gateway Control Function

Based on local configuration, the Breakout Gateway Control Function (BGCF) may be provisioned as the contact point within an operator’s network for transit IMS scenarios as described in clause 5.19. Otherwise the BGCF processes requests for routing from an S‑CSCF for the case were the S‑CSCF has determined that the session cannot be routed using DNS or ENUM/DNS (see clauses 5.4.3, 5.19 and 4.3.5 for more information).

The BGCF determines the next hop for routing the SIP message. This determination may be based on information received in the protocol, administrative information, and/or database access. For PSTN terminations, the BGCF determines the network in which PSTN/CS Domain breakout is to occur. If the routing determination is such that the breakout is to occur in the same network in which the BGCF is located, then the BGCF shall select a MGCF that will be responsible for the interworking with the PSTN/CS Domain. If the routing determination results in break out in another network, the BGCF will forward this session signalling to another BGCF in the selected network. If the routing determination results in the session being destined for another IMS network, the BGCF forwards the message to an I‑CSCF in this IMS network. If the BGCF determines that there is another IP destination for the next hop, it forwards the message to that contact point.

There may be multiple BGCFs within an operator’s network. The functions performed by the BGCF are:

– Determines the next hop for SIP routing.

– For PSTN terminations, select the network in which the interworking with the PSTN/CS Domain is to occur. If the interworking is in another network, then the BGCF will forward the SIP signalling to the BGCF of that network.

– For PSTN terminations, select the MGCF in the network in which the interworking with PSTN/CS Domain is to occur and forward the SIP signalling to that MGCF. This may not apply if the interworking is a different network.