For Multi-Media type services delivered via the IP-CAN within this architecture, a single session control protocol shall be used between the user equipment UE and the CSCF (over the Gm reference point).
Protocols over the Gm reference point :
The single protocol applied between the UE and CSCF (over the Gm reference point) within this architecture will be based on SIP (as defined by RFC 3261, other relevant IETF RFC's, and additional enhancements required to support 3GPP's needs).
A Single session control on the Mw, Mm, Mg, Mi, Mj, Mk, Mx:
A single session control protocol shall be used on the session control interfaces between:
MGCF and CSCF (Mg),
between CSCFs (Mw),
between a CSCF/IMS ALG and external IP networks (Mm),
between CSCF and BGCF (Mi),
between BGCF and MGCF (Mj),
between BGCF/IMS ALG and BGCF (Mk), and
between BGCF/CSCF and IBCF (Mx).
Protocols for the Mw, Mm, Mg, Mi, Mj, Mk, Mx:
The single session control protocol applied to these interfaces will be based on SIP (as defined by RFC 3261, other relevant IETF RFC's, and additional enhancements required to support 3GPP's needs).
UNI vs. NNI session control :
The SIP based signalling interactions between CN elements may be different than SIP based signalling between the UE and the CSCF.
Based on operator preference, border control functions may be applied between two IM CN subsystem networks or between an IM CN subsystem network and other SIP based multimedia network, see clause 4.14 and Annex I for details.
Restrict access from external networks :
The signalling solution shall allow the operator to restrict access from external networks (application level).
The following procedures are supported by an UE when accessing IMS:
Connect to the IP-CAN and acquire the necessary IP address, which includes, or is followed by, the P-CSCF discovery procedure. The mobility related procedures and IP address management principles for the IP-CAN are described in the relevant IP-CAN specifications;
Register to the IM subsystem as defined by the IMS registration procedures;
If an UE explicitly deactivates the IP-CAN bearer that is being used for IMS signalling, it shall first de-register from the IMS (while there is no IMS session in progress);
If an UE explicitly deactivates the IP-CAN bearer that is being used for IMS signalling while an IMS session is in progress, the UE must first release the session and de-register from the IMS and then deactivate the IP-CAN bearers;
If an UE changes its IP address according to IP-CAN procedures (e.g. TS 23.221), the UE shall re- register in the IMS by executing the IMS registration;
If an UE acquires an additional IP address due to establishing an additional IP-CAN bearer through a different access network, the UE may perform an IMS registration using this IP address as the contact address. If IMS registration is performed, this IMS registration may co-exist with the previous IMS registration from this UE and the UE shall be notified that this IMS registration results in multiple simultaneous registrations.
In order to be able to deliver an incoming IMS session, the IP-CAN bearer that is being used for IMS signalling need to remain active as long as the UE is registered in the IM CN subsystem;
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 RFC 3261 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 RFC 3261 or subsequent versions), i.e. in abnormal conditions it may terminate and independently generate SIP transactions.
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) with the Policy and Charging Architecture defined in TS 23.203; the P-CSCF may interact over the Rx interface (see TS 29.214) or over the N5 interface (using the Npcf_PolicyAutorization service, see TS 29.514) with the Policy and Charging Architecture defined in TS 23.503.
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.
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.
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.
Should perform SIP message compression/decompression.
Authorization of bearer resources and QoS management. For details see TS 23.203 and TS 23.503.
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.
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.
There may be multiple I-CSCFs within an operator's network. The functions performed by the I-CSCF are:
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 RFC 3966 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:
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:
May behave as a Registrar as defined in RFC 3261 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.
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 RFC 3261 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 RFC 3261 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.
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.
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 RFC 3312.
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.
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.
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:
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 clause 5.4.3, clause 5.19 and clause 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.
Generation of CDRs
The BGCF may make use of information received from other protocols, or may make use of administrative information, when making the choice of which network the interworking shall occur.
The architecture concerning the Multimedia Resource Function is presented in Figure 4.7 below.
(not reproduced yet)
Figure 4.7: Architecture of MRF
The MRF is split into Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP).
Tasks of the MRFC are the following:
Control the media stream resources in the MRFP.
Interpret information coming from an AS and S-CSCF (e.g. session identifier) and control MRFP accordingly.
Generate of CDRs.
Tasks of the MRFP include the following:
Control of the bearer on the Mb reference point.
Provide resources to be controlled by the MRFC.
Mixing of incoming media streams (e.g. for multiple parties).
Media stream source (for multimedia announcements).
Media stream processing (e.g. audio transcoding, media analysis).
Floor Control (i.e. manage access rights to shared resources in a conferencing environment).
Tasks of an Application Server with regards to MRF are e.g. the following:
Conference booking and management of booking information (e.g. start time, duration, list of participants)
The protocol used for the Mr and Mr' reference points is SIP (as defined by RFC 3261 , other relevant IETF RFCs, and additional enhancements introduced to support 3GPP's needs).
The Cr reference point allows interaction between an Application Server and an MRFC for media control. Further information on the Cr reference point is provided in TS 23.218.
The Mp reference point allows an MRFC to control media stream resources provided by an MRFP.
The Mp reference point has the following properties:
Full compliance with the H.248 standard.
Open architecture where extensions (packages) definition work on the interface may be carried out.
The protocol for the Mp reference point is described in TS 29.333.
The MRB supports the sharing of a pool of heterogeneous MRF resources by multiple heterogeneous applications. The MRB assigns (and later releases) specific suitable MRF resources to calls as requested by the consuming applications, based on MRF attributes specified by the applications as well as other criteria. For more information see TS 23.218.
IM CN Subsystem functional elements provide security, as needed, by security methods defined in TS 33.203 and TS 33.210. If interacting with external Networks, Security Associations are provided in accordance with operator policy.
IM CN subsystem functional elements provide support for offline and online charging. This includes support for charging correlation, e.g. between IM CN subsystem and PS domain. The charging architecture, charging principles and charging data for IM CN subsystem are described in TS 32.240 and TS 32.260. The charging correlation information between IM CN subsystem and PS domain are also described in TS 24.229 and TS 29.207 [11a].
The capabilities required for IMS group management are defined in clause 5.4 of TS 22.250. The Ut reference point is used to manage groups from the UE. This does not preclude the use of other mechanisms for group management, e.g. using OSA or OA&M mechanisms; the details of these other mechanisms are out of scope of this document.
The Ut reference point shall support a scenario where one single Application Server is used to create groups that can be utilized for different services, possibly hosted by different ASs.
It shall be possible to support the scenario where a NAT(-PT)/NAPT(-PT) residing between the IMS functionality in the UE and the P-CSCF has to be traversed for IMS communication. This shall include at least the types of NATs that implement address and port dependent mapping together with address and port dependent filtering, RFC 4787.