Content for TS 23.228 Word version: 19.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.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

E.2.2 The QoS requirements for an IM CN subsystem session E.2.2.0 General E.2.2.1 Relation of IMS media components and PDP contexts/EPS bearers carrying IMS media E.2.3 Interaction between GPRS/EPS QoS and session signalling E.2.3.0 General E.2.3.1 Resource Reservation with Policy and Charging Control E.2.4 Network initiated session release - P-CSCF initiated E.2.4.0 General E.2.4.1 Network initiated session release - P-CSCF initiated after loss of radio coverage E.3 Address and identity management concepts E.3.1 Deriving IMS identifiers from the USIM E.5 IP version interworking in IMS E.6 Usage of NAT in GPRS/EPS E.7 Retrieval of Network Provided Location Information in GPRS/EPS E.8 Geographical Identifier E.9 Support for Paging policy differentiation for IMS services E.10 Support of RAN Assisted Codec Adaptation
...

E.2.2 The QoS requirements for an IM CN subsystem session p. 223

E.2.2.0 General p. 223

The selection, deployment, initiation and termination of QoS signalling and resource allocation shall consider:

the general requirements described in clause 4.2.5.
for E-UTRAN access, the QoS handling is described in TS 23.401, TS 23.203.
for GERAN/UTRAN access, the requirements described in this clause so as to guarantee the QoS requirement associated with an IM CN subsystem session for IMS services.
1. QoS Signalling at Different Bearer Service Control Levels
  During the session set-up in a IM CN subsystem, at least two levels of QoS signalling/negotiation and resource allocation should be included in selecting and setting up an appropriate bearer for the session:
  1. The QoS signalling/negotiation and resource allocation at the IP Bearer Service (BS) Level:
    The QoS signalling and control at IP BS level is to pass and map the QoS requirements at the IP Multimedia application level to the UMTS BS level and performs any required end-to-end QoS signalling by inter-working with the external network. The IP BS Manager at the UE and the GGSN is the functional entity to process the QoS signalling at the IP BS level.
  2. The QoS signalling/negotiation and resource allocation at the UMTS Bearer Service Level:
    The QoS signalling at the UMTS BS Level is to deliver the QoS requirements from the UE (received from the GGSN in the case of IP-CAN Bearer Control) to the RAN, the CN, and the IP BS manager, where appropriate QoS negotiation and resource allocation are activated accordingly. When UMTS QoS negotiation mechanisms are used to negotiate end-to-end QoS, the translation function in the GGSN shall co-ordinate resource allocation between UMTS BS Manager and the IP BS Manager.
  Interactions (QoS class selection, mapping, translation as well as reporting of resource allocation) between the QoS signalling/control at the IP BS Level and the UMTS BS Level take place at the UE and the GGSN which also serve as the interaction points between the IM CN subsystem session control and the UMTS Bearer QoS control.
  UMTS specific QoS signalling, negotiation and resource allocation mechanisms (e.g. RAB QoS negotiation and PDP Context set-up) shall be used at the UMTS BS Level. Other QoS signalling mechanisms such as RSVP at the IP BS Level shall only be used at the IP BS Level.
  It shall be possible to negotiate a single resource allocation at the UMTS Bearer Service Level and utilise it for multiple sessions at the IP Bearer Service Level.

E.2.2.1 Relation of IMS media components and PDP contexts/EPS bearers carrying IMS media p. 224

All associated media flows (such as e.g. RTP / RTCP flows) used by the UE to support a single media component are assumed to be carried within the same PDP context/EPS bearer.

E.2.3 Interaction between GPRS/EPS QoS and session signalling p. 224

E.2.3.0 General p. 224

The generic mechanisms for interaction between QoS and session signalling are described in clause 5.4.7, the mechanisms described there are applicable to GERAN/UTRAN/E-UTRAN-accesses as well.

This clause describes the GERAN/UTRAN/E-UTRAN-access-specific concepts.

At PDP context/EPS bearer setup the user shall have access to either GPRS/EPS without Policy and Charging Control, or GPRS/EPS with Policy and Charging Control. The GGSN/P-GW shall determine the need for Policy and Charging Control, possibly based on provisioning and/or based on the APN of the PDN connection.

For the GPRS/EPS without Policy and Charging Control case, the bearer is established according to the user's subscription, local operator's IP bearer resource based policy, local operator's admission control function and GPRS/EPS roaming agreements.

For the GPRS/EPS with Policy and Charging Control case, policy decisions (e.g. authorization and control) are also applied to the bearer.

The GGSN/P-GW contains a Policy and Charging Enforcement Function (PCEF).

E.2.3.1 Resource Reservation with Policy and Charging Control p. 224

Depending on the Bearer Control Mode, as defined in TS 23.060, selected for the GPRS IP-CAN session, resource reservation shall be initiated either by the UE or by the IP-CAN itself. IMS media which require resource reservation is always mapped to a dedicated bearer, i.e. a dedicated EPS bearer or a PDP context activated using the Secondary PDP Context Activation Procedure. For IP-CAN initiated resource reservation, the PCRF has the responsibility to ensure that a dedicated bearer is used for media which require resource reservation.

For GERAN/UTRAN the UE initiates the activation or the modification of an existing PDP Context for the media parameters negotiated over SDP using the procedures for Secondary PDP-Context Activation and MS-Initiated PDP Context Modification respectively as defined in TS 23.060 subject to policy control.

Otherwise, the GGSN/P-GW within the GPRS IP-CAN initiates the activation or the modification of an existing PDP Context for the media parameters negotiated over SDP using the procedures for Network Requested Secondary PDP Context Activation and GGSN/P-GW-Initiated PDP Context Modification respectively as defined in TS 23.060.

For E-UTRAN, the UE initiates the resource reservation request for the media parameters negotiated over SDP using procedure UE Requested Bearer Resource Modification procedure as defined in TS 23.401 subject to policy control.

Otherwise, the P-GW within the EPS IP-CAN initiates the activation or the modification of an existing Dedicated EPS bearer for the media parameters negotiated over SDP using the procedures for Dedicated bearer activation and PDN GW initiated bearer modification with or without bearer QoS update as specified in TS 23.401.

The request for GPRS/EPS QoS resources may be signalled independently from the request for IP QoS resources by the UE. At the GPRS/EPS BS Level, the PDP Context activation / UE Requested Bearer Resource Modification shall be used by the UE for QoS signalling. At the IP BS Level, RSVP may be used for QoS signalling.

E.2.4 Network initiated session release - P-CSCF initiated p. 225

E.2.4.0 General p. 225

In the event of loss of coverage for GERAN/UTRAN access, TS 23.060 defines the Iu or RAB Release procedures. In the case of PDP context/EPS bearer with streaming or conversational class the maximum bitrate of the GTP tunnel between SGSN and GGSN or between SGSN and S-GW/P-GW is modified to 0 kbit/s in up- and downlink direction. This is indicated to the P-CSCF/PCRF by performing an IP-CAN session modification procedure (see TS 23.203) as shown in Figure E.3. This procedure also applies to PDP Contexts/EPS bearer used for IMS SIP Signalling transport. For loss of coverage in the case of other PDP contexts/EPS bearer (background or interactive traffic class), the PDP context/EPS bearer is preserved with no modifications and therefore no indication to the P-CSCF/PCRF.

In the event of loss of coverage for E-UTRAN access, TS 23.401 defines the S1 release Procedure. This procedure releases the EPS bearers. This is indicated to the P-CSCF/PCRF by performing an IP-CAN session modification procedure (see TS 23.203) as shown in Figure E.3. The UE will become aware of the release of the GBR bearer the next time it accesses the E-UTRAN network via the procedures as described in the clauses 5.3.3 and 5.3.4 of TS 23.401.

E.2.4.1 Network initiated session release - P-CSCF initiated after loss of radio coverage p. 225

Reproduction of 3GPP TS 23.228, Fig. E.3: Network initiated session release - P-CSCF initiated after loss of radio coverage

Figure E.3: Network initiated session release - P-CSCF initiated after loss of radio coverage

Step 1.

In the case of GERAN/UTRAN access, in the event of loss of radio coverage for a PDP context with streaming or conversational class the maximum bitrate of the GTP tunnel between SGSN and GGSN and between SGSN and S-GW /P-GW is modified to 0 kbit/s in up- and downlink direction. The P-CSCF/PCRF receives an indication of PDP context/EPS bearer modification or EPS bearer removal. This also applies to PDP Contexts/EPS bearer used for IMS SIP Signalling transport.

In the case of E-UTRAN access, loss of radio coverage causes the GBR bearers to be released in the network and P-CSCF/PCRF is notified appropriately.

Step 2.

It is optional for the P-CSCF/PCRF to deactivate the affected bearer and additional IP bearers (e.g. an IP bearer for chat could still be allowed). If the P-CSCF decides to terminate the session then the P-CSCF/PCRF removes the authorization for resources that had previously been issued for this endpoint for this session (see TS 23.203).

Step 3.

The P-CSCF decides on the termination of the session. In the event of the notification that the signalling transport to the UE is no longer possible, the P-CSCF shall terminate any ongoing session with that specific UE. If the P-CSCF decides to terminate the session then the P-CSCF/PCRF removes the authorization for resources that had previously been issued for this endpoint for this session. (see TS 23.203).

The following steps are only performed if the P-CSCF/PCRF has decided to terminate the session.

When receiving an indication that bearer resources are not available for a voice media negotiated in a multimedia session that is in pre-alerting phase e.g. due to weak E-UTRAN coverage, the P-CSCF performs the procedures according to clause 6.2.1.3a or clause 6.2.2.3a in TS 23.237.

Step 4.

The P-CSCF generates a Hangup (Bye message in SIP) to the S-CSCF of the releasing party.

Step 5.

The S-CSCF invokes whatever service logic procedures are appropriate for this ending session.

Step 6.

The S-CSCF of the releasing party forwards the Hangup to the S-CSCF of the other party.

Step 7.

The S-CSCF invokes whatever service logic procedures are appropriate for this ending session.

Step 8.

The S-CSCF of the other party forwards the Hangup on to the P-CSCF.

Step 9.

The P-CSCF/PCRF removes the authorization for resources that had previously been issued for this endpoint for this session. This step also results in a release indication to the GPRS/EPS system to confirm that the IP bearers associated with the session have been deleted for UE#2.

Step 10.

The P-CSCF forwards the Hangup on to the UE.

Step 11.

The UE responds with an acknowledgement, the SIP OK message (number 200), which is sent back to the P-CSCF.

Step 12.

The IP network resources that had been reserved for the message receive path to the UE for this session are now released. Depending on the Bearer Control Mode selected for the IP-CAN session, the release of previously reserved resources shall be initiated either by the UE or by the IP-CAN itself. The UE initiates the release of the IP-CAN bearer resources as shown in Figure E.3. Steps 12 and 13 may be done in parallel with step 11. Otherwise, the GGSN/P-GW within the GPRS/EPS IP-CAN initiates the release of the bearer PDP context/EPS bearer deactivation after step 9 instead.

Step 13.

The GPRS/EPS system releases the PDP context/EPS bearer. The IP network resources that had been reserved for the message receive path to the UE for this session are now released. This is initiated from the GGSN/P-GW. If RSVP was used to allocated resources, then the appropriate release messages for that protocol would invoked here.

Step 14.

The SIP OK message is sent to the S-CSCF.

Step 15.

The S-CSCF of the other party forwards the OK to the S-CSCF of the releasing party.

Step 16.

The S-CSCF of the releasing party forwards the OK to the P-CSCF of the releasing party.

E.3 Address and identity management concepts p. 226

E.3.1 Deriving IMS identifiers from the USIM p. 226

If the UICC does not contain an ISIM application, then:

The Private User Identity shall be derived from the USIM's IMSI, which allows for uniquely identifying the user within the 3GPP operator's network. The format of the Private User Identity derived from the IMSI is specified in TS 23.003.
A Temporary Public User Identity shall be derived from the USIM's IMSI, and shall be used in SIP registration procedures. The format of the Temporary Public User Identity is specified in TS 23.003.

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.

In order to support a pre-Rel-5 UICC accessing IMS services, a Temporary Public User Identity is generated using an appropriate identity related to the subscriber's subscription (e.g. in 3GPP it shall use the IMSI).

When a Temporary Public User 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.

E.4 Void

E.5 IP version interworking in IMS p. 227

A PDP context & its associated additional PDP contexts (i.e. PDP contexts associated to the same IP address/prefix) support either PDP type IPv4 or IPv6 or IPv4v6. For communication with the IMS, the UE establishes an IPv4 PDN connection or an IPv6 PDN connection or an IPv4IPv6 PDN connection via PDP contexts/EPS bearers. Termination of this PDP context/EPS bearer will normally trigger de-registration of IMS application first. Hence, the PDP context/EPS bearer that has been established for IMS communication must be retained for the UE to establish a SIP session via the IMS with an IPv4 SIP client.

As such, any interworking on IP version on the application level (i.e. IMS & SIP) need to work with the architecture requirement from GPRS/EPS of maintaining the IP connectivity over GPRS/EPS by maintaining the PDP contexts/EPS bearers.

For IMS perspective, a user may be connected either to a home GGSN/P-GW or a visited GGSN/P-GW depending on the configuration as specified in TS 23.221.

E.6 Usage of NAT in GPRS/EPS |R7| p. 227

There should be no NAT (or its existence should be kept transparent towards the UE) located between the GGSN/P-GW and the P-CSCF, which is possible as they are either located within the same private network and share same address space, or both the UE and the P-CSCF are assigned globally unique IP addresses (see Annex M).

E.7 Retrieval of Network Provided Location Information in GPRS/EPS |R11| p. 228

Information related to the location of the user provided by the access network may be required in IMS in order to comply with regulatory requirements (e.g. data retention, lawful interception) and/or in order to enable certain types of added value services based on the user's location.

Depending on usage scenario, the following mechanisms are defined and can be used to retrieve the user location and/or UE Time Zone information from the access network when using GPRS and/or EPS to access IMS:

The P-CSCF can retrieve the user location and/or UE Time Zone information using PCC mechanisms as specified in TS 23.203 and in TS 29.214. Operator policy determines whether to provide the user location and/or UE Time Zone information from the access network in the INVITE request, a MESSAGE request, or within a subsequent message of the dialog.
When the user location and/or UE Time Zone information is required from the access network but not already available (e.g. when required in an INVITE request, when it is needed prior to session delivery, or when call is broken out to a MGCF), an IMS AS can trigger the retrieval of the user location and/or UE Time Zone information from the SGSN/MME via the HSS as specified in TS 29.328 and as described in clause 4.2.4a.

Operator policies at P-CSCF and IMS AS need to be coordinated in order to ensure that the appropriate method to retrieve the user location and/or UE Time Zone information is used for specific scenarios according to operator's preferences. The IMS entity that retrieves the user location and/or UE Time Zone information shall have the capability to further distribute the information to other IMS entities once it has been retrieved. User location and/or UE Time Zone information provided in the signalling by the network shall be possible to distinguish from user location information provided by the UE. The transfer of the user location and/or UE Time Zone information within IMS signalling shall not affect the transfer of any UE provided user location information. Information flows on how user location and/or UE Time Zone information can be further distributed within IMS depending on the alternative mechanism used can be found in Annex R.

The level of granularity of user location information may be changed at network/trust boundaries. Thus, the level of user location information granularity that can be retrieved by an IMS AS via the HSS-based procedures in roaming scenarios depends on inter-operator agreement, and needs to be aligned with policies in the P-CSCF.

Information related to the location of the user provided by the access network may be required in IMS in order to comply with regulatory requirements for SMS over IP. The P-CSCF applies the above mechanisms upon reception of a MESSAGE including the distribution of received information to other IMS entities.

E.8 Geographical Identifier |R11| p. 228

The Geographical Identifier identifies a geographical area within a country or territory. It may be described in a geospatial manner (e.g. geodetic coordinates) within a country or territory or as civic user location information (e.g. a postcode, area code, etc.), or use an operator-specific format. It is assumed that a given cell cannot belong to more than one area identified by a Geographical Identifier.

A network which requires the Geographical Identifier to be generated in the IMS may implement a mapping table between an (E)CGI (received as part of Access Network Information) and a Geographical Identifier. The P-CSCF or an IMS AS may then, based on operator policy, use this mapping table to convert the user location into a Geographical Identifier, and insert the Geographical Identifier in the SIP signalling, thus enabling routing decision in downstream IMS entities or interconnected network.

E.9 Support for Paging policy differentiation for IMS services |R13| p. 228

As a network configuration option, where P-CSCF and P-GW are located in the same PLMN, it shall be possible for the P-CSCF for terminating signalling to identify conversational voice as defined in IMS multimedia telephony service, TS 22.173.

P-CSCF may support Paging Policy Differentiation (as defined in TS 23.401) for a specific IMS service by marking packet(s) to be send towards the UE related to that IMS service. For such an IMS service, a specific DSCP (IPv4) value and/or a specific Traffic Class (IPv6) value are assigned by local configuration in the P-CSCF.

When Paging Policy Differentiation is deployed in a PLMN, all P-CSCF entities of that PLMN shall homogeneously support it and shall be configured with the same policy for setting the specific DSCP (IPv4) and/or Traffic Class (IPv6) values used by P-CSCF for that feature.

E.10 Support of RAN Assisted Codec Adaptation |R16| p. 229

RAN assisted codec adaptation is a functionality that assists codec rate adaptation for Multimedia Telephony based on access network bitrate recommendation (ANBR) messages that the UE receives in the access stratum of the 3GPP access network (E-UTRA RAT). The functionality is defined in TS 26.114 and affects the following system entities: UE, RAN, P-CSCF and PCRF/PCF.

During SIP registration or emergency registration if the network supports ANBR as specified in TS 26.114 and RAN-assisted codec adaptation as specified in TS 36.300 and TS 36.321, the P-CSCF indicates 'anbr' support to the UE.

As specified in TS 26.114:

support for RAN assisted codec adaptation can be used only if it is supported end-to-end.
support for RAN assisted codec adaptation is assumed to be homogeneous in a PLMN i.e. all affected system entities in a PLMN including equivalent PLMNs need to support it. RAN support is required on E-UTRA.
the UE includes the 'anbr' attribute in the SDP offer only if the P-CSCF has indicated its ability to handle it.
the P-CSCF forwards the 'anbr' attribute if it has received it in the SDP offer from the UE.
when the 'anbr' attribute is successfully negotiated end-to-end, the PCRF/PCF uses MBR > GBR setting for the corresponding IP-CAN bearer relying on RAN assisted codec adaptation.

A UE supporting Multimedia Telephony and RAN assisted codec adaptation shall support the procedures described in TS 26.114.

F Routing subsequent requests through the S-CSCF |R6| p. 230

This annex provides some background information related to clause 5.4.5.3.

The S-CSCF is the focal point of home control. It guarantees operator control over sessions. Therefore IMS has been designed to guarantee that all initial session signalling requests goes through the Home S-CSCF on both terminating and originating side. A number of tasks performed by the S-CSCF are performed either at registration time or immediately during session set-up, e.g. evaluation of initial filter criteria. However, there are tasks of the S-CSCF, which require the presence of the S-CSCF in the signalling path afterwards:

Media parameter control: If the S-CSCF finds media parameters that local policy or the user's subscriber profile does not allow to be used within an IMS session, it informs the originator. This requires record-routing in the S-CSCF. For example, change of media parameters using UPDATE would by-pass a S-CSCF, which does not record-route.
CDR generation: The S-CSCF generates CDRs, which are used for offline charging and for statistical purposes. A S-CSCF, which does not record-route, would not even be aware of session termination. If the CDRs at the S-CSCF are needed, then the S-CSCF must record-route.
Network initiated session release: The S-CSCF may generate a network-initiated session release, e.g. for administrative reasons. For that purpose a S-CSCF needs to be aware of ongoing sessions. In particular it must be aware of hard state dialogs that are required to be terminated by an explicit SIP request.
If a UE registered to the S-CSCF uses a Globally Routable User Agent URI (GRUU) assigned by the S-CSCF as a contact address when establishing a dialog, then the S-CSCF needs to remain in the signalling path in order to translate mid-dialog requests addressed to that contact address.

The above criteria are particularly important for "multimedia telephony" type peer-to-peer communication.

Media parameter control guarantees that the user does not use services he or she did not pay for.
For telephony type services the session charging component is the most important one.
If a subscriber is administratively blocked, the network shall have the possibility to terminate ongoing communication.

More generally, all the tasks are needed; thus they need to be provided elsewhere if the S-CSCF does not record-route.

On the other hand there are client-server based services, which may be offered by the home operator. An example of such service available today where the no record route principle is applied, is Presence, where notifications need not go through the S-CSCF. Another example could be where the UE initiates a session to an Application Server (AS) in the home operator's domain, e.g. video download. In such cases:

The server implementation (or the server's knowledge of user subscription data) may limit the allowed media parameters.
Charging will be mostly event-based charging (content charging) and depends on the information provided from the AS.
The AS can terminate sessions. And the dialogs may be soft state dialogs, which are not required to be terminated by an explicit SIP request (e.g. SUBSCRIBE dialogs).

However not in all cases the AS would receive the necessary information, which usually triggers session release (e.g. for administrative reasons).

Thus, for some client-server based services, it might not be necessary to keep the S-CSCF in the path. It may be desirable for an operator to avoid the load in the S-CSCF and control the service from the AS. For such services "no record-routing in S-CSCF" may be configured together with the initial filter criteria, as defined in clause 5.4.5.3.