Content for TS 23.203 Word version: 18.0.0

0… 4… 5… 6… 6.1.4… 6.1.7… 6.1.10… 6.1.17… 6.2… 6.2.2… 6.2.3… 6.3 6.4… 6.8… 7… 7.3… 7.4… 7.7… 7.7.3… 7.8… A… A.4… D… P… P.4.2.4… P.7… P.7.5… P.8 Q… S… S.7… S.8.8 T…

6.1.10 IMS Emergency Session Support 6.1.10.1 Architecture model and Reference points 6.1.10.2 PCC Rule Authorization and QoS rule generation 6.1.10.3 Functional Entities 6.1.10.4 PCC Procedures and Flows 6.1.10a Restricted Local Operator Services Support 6.1.11 Multimedia Priority Service Support 6.1.11.1 Architecture model and Reference points 6.1.11.2 PCC rule authorization and QoS rule generation 6.1.11.3 Priority EPS Bearer Service 6.1.11.4 Bearer priority for IMS Multimedia Priority Services 6.1.11.5 Bearer priority for MPS for Data Transport Service 6.1.12 ADC rule authorization 6.1.13 Redirection 6.1.14 Resource sharing for different AF sessions 6.1.15 Reporting of RAN user plane congestion information 6.1.16 Negotiation for future background data transfer
...

6.1.10 IMS Emergency Session Support |R9| p. 60

6.1.10.1 Architecture model and Reference points p. 60

Emergency bearer services (i.e. IP-CAN session for the IMS emergency services) are provided by the serving network to support IMS emergency when the network is configured to support emergency services. Emergency services are network services provided through an Emergency APN and may not require a subscription depending on operator policies and local regulatory requirements. For emergency services the architecture for the non-roaming case as described in clause 5.1 is the only applicable architecture model.

For emergency services, the Sp reference point does not apply.

Emergency services are handled locally in the serving network. Therefore the S9 reference point does not apply.

6.1.10.2 PCC Rule Authorization and QoS rule generation p. 60

The PCC Rule Authorization and QoS Rule generation function selects QoS parameters that allow prioritization of IMS Emergency sessions. If an IMS Emergency session is prioritized the QoS parameters shall contain an ARP value that is reserved for intra-operator use of IMS Emergency services.

6.1.10.3 Functional Entities p. 60

6.1.10.3.1 PCRF p. 60

The PCRF shall determine based on the PDN-id if an IP-CAN Session concerns an IMS emergency session.

For an IP-CAN session serving an IMS emergency session, the PCRF makes authorization and policy decisions that restrict the traffic to emergency destinations, IMS signalling and the traffic to retrieve user location information (in the user plane) for emergency services. An IP-CAN session serving an IMS emergency session shall not serve any other service and shall not be converted to/from any IP-CAN session serving other services.

If the UE IP address belongs to an emergency APN, the PCRF does not perform subscription check; instead it utilizes the locally configured operator policies to make authorization and policy decisions.

For IMS, it shall be possible for the PCRF to verify that the IMS service information is associated with a UE IP address belonging to an emergency APN. If the IMS service information does not contain an emergency related indication and the UE IP address is associated with an emergency APN, the PCRF shall reject the IMS service information provided by the P-CSCF (and thus to trigger the release of the associated IMS session), see TS 23.167.

The PCRF performs according to existing procedure:

If IMS service information containing an emergency related indication is received from the P-CSCF with an UE IP address associated to an Emergency APN, the PCRF initiates an IP-CAN session Modification Request for the IP-CAN session serving the IMS session to the PCEF to provide PCC Rule(s) that authorize media flow(s).
At reception of an indication that the IMS emergency session is released from the P-CSCF, the PCRF removes the PCC rule(s) for that IMS session with an IP-CAN session Modification Request.

In addition, upon Rx session establishment the PCRF shall provide the IMEI(SV) (if available) and the EPC-level subscriber identifiers (IMSI, MSISDN) (if available), received from the PCEF at IP-CAN session establishment, if so requested by the P-CSCF.

6.1.10.3.2 PCEF p. 60

The PCEF initiates the IP-CAN Session termination if the last PCC rule for this IP-CAN session is removed according to existing procedure.

In addition, at reception of an IP-CAN Session Modification Request triggered by the PCRF for an IP-CAN session serving an IMS emergency session that removes all PCC rules with a QCI other than the default bearer QCI and the QCI used for IMS signalling, the PCEF shall start a configurable inactivity timer (e.g., to enable PSAP Callback session). When the configured period of time expires the PCEF shall initiate an IP-CAN Session Termination Request for the IP-CAN session serving the IMS Emergency session.

If a PCRF-Initiated IP-CAN Session Modification Request, providing new PCC rule(s) with a QCI other than the default bearer QCI and the QCI used for IMS signalling, the PCEF shall cancel the inactivity timer.

6.1.10.3.3 P-CSCF p. 61

The P-CSCF performs according to existing procedure:

At reception of an indication that an IMS emergency session is established, the P-CSCF sends IMS service information to the PCRF.
At reception of an indication that an IMS emergency session is released, the P-CSCF interacts with the PCRF to revoke the IMS service information.

In addition, the P-CSCF shall include an emergency related indication when providing IMS service information to the PCRF; see TS 23.167.

Moreover, the P-CSCF upon Rx session establishment may request the PCRF to provide the IMEI(SV) and the EPC-level subscriber identifiers (IMSI, MSISDN) corresponding to the Rx session.

6.1.10.4 PCC Procedures and Flows p. 61

At Indication of IP-CAN Session Establishment that includes a PDN-id that identifies an Emergency APN the PCRF ignores subscription information from the SPR. The PCRF uses locally configured operator policies to make authorization and policy decisions.

At Indication of IP-CAN Session Establishment and Gateway Control Session Establishment, the user identity (e.g. IMSI) may not be available, or can not be authenticated. In this case, the IMEI shall be used to identify the UE.

An IP-CAN session for an emergency service shall be restricted to the destination address(es) associated with the emergency service only.

6.1.10a Restricted Local Operator Services Support |R16| p. 61

Restricted Local Operator Services (i.e. IP-CAN session for the Restricted Local Operator Services) (as specified in TS 23.221) are provided by the serving network when the network is configured to support Restricted Local Operator Services.

The PCC handling of Restricted Local Operator Services is very similar to that of emergency service as specified in clause 6.1.10 with the following differences:

RLOS APN and IMS RLOS session are used for Restricted Local Operator Services.
Architecture model and Reference points (clause 6.1.10.1).
Restricted Local Operator Services do not require a subscription.
PCC Rule Authorization and QoS rule generation (clause 6.1.10.2).
The Restricted Local Operator Services is not a prioritized services, and the ARP can be determined based on operator policy.
Functional Entity: PCRF (clause 6.1.10.3.1).
The PCRF shall determine based on the RLOS APN if an IP-CAN Session relates to an IMS RLOS session.
Functional Entity: PCEF (clause 6.1.10.3.2).
Duration of PDN connection for RLOS is controlled through local policies in PCEF. Handling of inactivity timer for the emergency PDN connection is not applicable for RLOS.
Functional Entity: P-CSCF (clause 6.1.10.3.3).
Indication of IMS RLOS session is used.
PCC Procedures and Flows (clause 6.1.10.4).
The PDN-id identifies an RLOS APN.

6.1.11 Multimedia Priority Service Support |R10| p. 62

6.1.11.1 Architecture model and Reference points p. 62

Subscription data for MPS is provided to PCC through the Sp reference point. To support MPS service, the PCRF shall subscribe to changes in the MPS subscription data for Priority EPS Bearer Service. Dynamic invocation for MPS is provided from an AF, using the Priority indicator, over Rx.

6.1.11.2 PCC rule authorization and QoS rule generation p. 62

For MPS service, the PCRF shall generate the corresponding PCC/QoS rule(s) with the ARP/QCI parameters as appropriate for the prioritized service.

For non-MPS service, the PCRF shall generate the corresponding PCC/QoS rule(s) as per normal procedures, without consideration whether the MPS Priority EPS Bearer Service is active or not, but upgrade the ARP/QCI values suitable for MPS when the Priority EPS Bearer Service is invoked. When the priority EPS Bearer Service is revoked, the PCRF shall change ARP/QCI values modified for Priority EPS bearer service to an appropriate value according to PCRF decision.

Whenever one or more AF sessions of an MPS service are active within the same PDN connection, the PCRF shall ensure that the ARP priority level of the default bearer is at least as high as the highest ARP priority level used by any authorized PCC rules belonging to an MPS service. If the ARP pre-emption capability is enabled for any of the authorized PCC rules belonging to an MPS service, the PCRF shall also enable the ARP pre-emption capability for the default bearer.

6.1.11.3 Priority EPS Bearer Service p. 62

The MPS Priority EPS Bearer Service targets the ARP and/or QCI of bearer(s), enabling the prioritization of all traffic on the same bearer.

The PCRF shall, at the activation of the Priority EPS Bearer Service:

modify the ARP of the default bearer as appropriate for the Priority EPS Bearer Service under consideration of the requirement described in clause 6.1.11.2; and
if modification of the QCI of the default bearer is required, modify the QCI of the default bearer as appropriate for the Priority EPS Bearer Service; and
modify the ARP of PCC/QoS Rules installed before the activation of the Priority EPS Bearer Service to the ARP as appropriate for the Priority EPS Bearer Service under consideration of the requirement described in clause 6.1.11.2; and
if modification of the QCI of the PCC/QoS Rules is required, modify the QCI of the PCC/QoS Rules installed before the activation of the Priority EPS Bearer Service to the QCI as appropriate for the Priority EPS Bearer Service.

The PCRF shall, at the deactivation of the Priority EPS Bearer Service:

modify the ARP of the default bearer to an appropriate value according to PCRF decision under consideration of the requirement described in clause 6.1.11.2; and
if modification of the QCI of the default bearer is required, modify the QCI of the default bearer to an appropriate value according to PCRF decision; and
for PCC/QoS rules modified due to the activation of Priority EPS bearer service:
- modify the ARP to an appropriate value according to PCRF decision under consideration of the requirement described in clause 6.1.11.2; and
- if modification of the QCI of PCC/QoS Rules is required, modify the QCI to an appropriate value according to PCRF decision.

6.1.11.4 Bearer priority for IMS Multimedia Priority Services p. 63

In addition to the mechanism specified in clause 6.1.11.2, IMS Multimedia Priority Services may require upgrade of the dedicated IM CN signalling bearer and the default bearer, e.g. in order to mitigate the IP-CAN session termination due to resource limitation at a location change the default bearer and dedicated IM CN signalling bearer may need an upgraded ARP.

At reception of the indication that the IMS Signalling Priority is set for the IP-CAN Session or at reception of service authorization from the P-CSCF (AF) including an MPS session indication and the service priority level the PCRF shall under consideration of the requirement described in clause 6.1.11.2:

modify the ARP of the default bearer as appropriate for the IMS Multimedia Priority Service; and
if upgrade of the dedicated IM CN signalling bearer is required, modify the ARP in all the PCC/QoS rules that describe the IM CN signalling traffic to the value appropriate for IMS Multimedia Priority Services.

When the PCRF detects that the P-CSCF (AF) released all the MPS session and the IMS Signalling Priority is not set for the IP-CAN session the PCRF shall under consideration of the requirement described in clause 6.1.11.2:

modify the ARP of the default bearer to an appropriate value according to PCRF decision; and
modify the ARP in all PCC/QoS Rules that describe the IM CN signalling traffic to an appropriate value according to PCRF decision.

6.1.11.5 Bearer priority for MPS for Data Transport Service |R17| p. 63

MPS for Data Transport Service enables the prioritization of all traffic on the default bearer and other bearers upon AF request. The QoS modification to the default bearer and other bearers is done based on operator policy and regulatory rules by means of local PCRF configuration.

Upon receipt of an MPS for Data Transport Service invocation/revocation request from the UE, the AF or the PCRF authorizes the request. If the UE has an MPS subscription, MPS for Data Transport Service is authorized by the AF or the PCRF, based on AF decision. If the Service User is using a UE that does not have an MPS subscription, the AF authorizes MPS for Data Transport Service.

In the case that the AF authorizes the MPS for Data Transport Service request, after successful authorization, the AF sends the MPS for Data Transport Service request to the PCRF over Rx for QoS modifications, including an indication that PCRF authorization is not needed. In this case, the PCRF shall not perform a subscription check for MPS for Data Transport Service requests. The AF also indicates to the PCRF whether the request is for invoking or revoking MPS for Data Transport Service.
In the case that the AF does not authorize the MPS for Data Transport Service request, the AF sends the request over Rx to the PCRF for authorization and QoS modifications, including an indication that PCRF authorization is needed. In this case, the PCRF shall perform an MPS subscription check for the MPS for Data Transport Service request. The AF also indicates whether the request is for invoking or revoking MPS for Data Transport Service. The PCRF will inform the AF when the UE does not have an MPS subscription associated with the request.

After successful authorization by either AF or PCRF as described above, the PCRF shall, at the activation of MPS for Data Transport Service over Rx, perform the same steps for QoS modifications as described in clause 6.1.11.3 for the activation of the Priority EPS Bearer Service.

The PCRF shall inform the AF of the success or failure of the MPS for Data Transport Service invocation/revocation request.

The PCRF shall at the deactivation of MPS for Data Transport Service over Rx perform the same steps described in clause 6.1.11.3 for the deactivation of the Priority EPS Bearer Service.

If the bearers are deactivated for other reasons than an AF request, the PCRF shall notify the AF by terminating the Rx session.

The AF may also request an SDF for priority signalling between the UE and the AF, where the AF includes the Priority indicator over Rx, in order to enable the PCRF to set appropriate QoS values for the signalling bearer.

6.1.12 ADC rule authorization |R11| p. 64

ADC Rule authorization refers to the PCRF decision about which predefined and/or dynamic ADC rules to activate for a TDF session and is only applicable in case of solicited application reporting.

It may also comprise the selection of parameters (monitoring key, enforcement actions etc.) for dynamic ADC rules to be applied once the traffic is detected.

User profile configuration, received within subscription information, indicating whether application detection and control can be enabled, shall be taken into account by PCRF, when deciding on ADC rule authorization.

6.1.13 Redirection |R11| p. 64

Redirection of application traffic is an option applicable in the TDF or the PCEF enhanced with ADC.

PCRF may control redirection by provisioning and modifying dynamic ADC rules over the Sd interface for a TDF, or dynamic PCC rules over the Gx interface for a PCEF enhanced with ADC. The PCRF may enable/disable redirection and set a redirect destination for every dynamic ADC rule or PCC rule.

Redirect information (redirection enabled/disabled and redirect destination) within a PCC Rule or within an ADC rule respectively, instructs the PCEF enhanced with ADC, or the TDF whether or not to perform redirection towards a specific redirect destination. The redirect destination may be provided as part of the dynamic PCC/ADC Rule, or may be preconfigured in the PCEF enhanced with ADC or the TDF. A redirect destination provided in a dynamic PCC/ADC Rule overrides the redirect destination preconfigured in the PCEF enhanced with ADC or in the TDF for this PCC/ADC Rule.

The redirection is enforced by the PCEF enhanced with ADC or the TDF on uplink application's traffic matching the ADC or PCC rule for which redirection is enabled.

6.1.14 Resource sharing for different AF sessions |R13| p. 64

The P-CSCF (i.e. AF) may indicate to the PCRF that media of an AF session may share resources with media belonging to other AF sessions according to TS 23.228. For every media flow, the P-CSCF may indicate that the media flow may share resources in both directions or in one direction only (UL or DL).

The PCRF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC/QoS rule for every media flow in any AF session.

If the PCRF received identical indication(s) for resource sharing for multiple AF sessions, the PCRF may request the PCEF/BBERF to realize resource sharing for the corresponding set of PCC/QoS rules. The PCRF provides a DL and/or UL sharing indication with the same value for those PCC/QoS Rules that are candidate to share resources according to the direction of resource sharing indicated by the AF.

For each direction, the PCEF/BBERF shall take the highest GBR value from each set of PCC/QoS Rules related with the same sharing indication for this direction and bound to the same bearer and uses that value as input for calculating the GBR of the bearer. For each direction, the PCEF/BBERF may take the MBR value of the most demanding PCC/QoS Rule included in each set of PCC Rules related with the same sharing indication for this direction and bound to the same bearer and uses that as input for calculating the MBR of the bearer.

The AF session termination or modification procedure that removes media flows triggers the removal of the corresponding PCC/QoS Rules from the PCEF/BBERF. The PCEF/BBERF shall recalculate the GBR (and MBR) value of the bearer whenever a set of PCC/QoS Rules with the same sharing indication changes.

Resource sharing is applied as long as there are at least two active PCC/QoS rules with the same sharing indication bound to the same bearer.

Resource sharing for different AF sessions is possible only if the P-CSCF, the PCRF and the PCEF/BBERF support it.

6.1.15 Reporting of RAN user plane congestion information |R13| p. 65

6.1.15.1 General p. 65

RAN User Plane Congestion Information (RUCI) is reported to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for policy decisions.

The RUCI includes the following information:

The IMSI identifying the UE impacted by congestion;
eNB identifier, ECGI or SAI identifying the eNB, E-UTRAN cell or Service Area, respectively, serving the UE.

NOTE:
Whether in case of E-UTRAN the eNB identifier or the ECGI is included in the RUCI is up to operator configuration in the RCAF.
APN for which congestion information is reported;
Congestion level or an indication of the "no congestion" state.

6.1.15.2 Reporting restrictions p. 65

Depending on the operator's congestion mitigation policy, it may not be necessary to have RUCI reporting for all users. An operator shall be able to specify restrictions for RUCI reporting on a per UE per APN basis. Reporting restrictions can be used to activate or deactivate the RUCI reporting. Reporting restrictions can also be used to limit RUCI reporting. This is achieved by defining one or more sets of congestion levels, such that the RCAF indicates only that the UE experiences a congestion level within the given set but does not indicate the congestion level itself within that set. The sets must be non-overlapping such that a congestion level belongs to a single set only. Reporting restrictions can also be used to deactivate reporting of the congested cell's identifier as part of the RUCI.

6.1.15.3 UE mobility between RCAFs p. 65

A RCAF is assumed to serve a geographical area. A UE may move from the area handled by one RCAF to an area handled by a different RCAF. RCAF nodes cannot detect mobility by themselves: an RCAF node cannot differentiate whether a UE that is no longer affected by congestion has moved to another RCAF or not. When a given RCAF indicates no congestion to the PCRF for a given UE on the Np interface, this should be interpreted as no congestion experienced at the given RCAF which does not exclude that another RCAF may report that the same UE experiences congestion.

Consistent operation for UE mobility is ensured by applying the following rules at the PCRF.

The PCRF maintains the RCAF which has last indicated that the UE is affected by congestion.
When a new RCAF indicates that the UE is affected by congestion, the PCRF sends a message to the old RCAF to explicitly release context at the old RCAF.

6.1.16 Negotiation for future background data transfer |R13| p. 66

The AF may contact the PCRF via the SCEF (and the Nt interface) to request a time window and related conditions for future background data transfer.

The AF request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window and optionally, network area information (e.g. list of cell ids, TAs/RAs).

The PCRF shall first retrieve all existing transfer policies stored for any ASP from the SPR. Afterwards, the PCRF shall determine, based on the information provided by the AF and other available information (e.g. network policy, congestion level (if available), load status estimation for the required time window and network area, existing transfer policies) one or more transfer policies.

A transfer policy consists of a recommended time window for the background data transfer, a reference to a charging rate for this time window and optionally a maximum aggregated bitrate (indicating that the charging according to the referenced charging rate is only applicable for the aggregated traffic of all involved UEs that stays below this value). Finally, the PCRF shall provide the transfer policies to the AF together with a reference ID. If the AF received more than one transfer policy, the AF shall select one of them and inform the PCRF about the selected transfer policy.

The selected transfer policy is finally stored by the PCRF in the SPR together with the reference ID and the network area information. The same or a different PCRF can retrieve this transfer policy and the corresponding network area information from the SPR and take them into account for future decisions about transfer policies for background data related to the same or other ASPs.

At the time the background data transfer is about to start, the AF provides for each UE the reference ID together with the AF session information to the PCRF (via the Rx interface). The PCRF retrieves the corresponding transfer policy from the SPR and derives the PCC rules for the background data transfer according to this transfer policy.