7.10 Procedures over Np reference point

23.2033GPPPolicy and charging control architectureRelease 17TS

7.10.1 Report RAN user plane congestion information to PCRF

This clause describes the signalling flow for reporting RUCI (RAN User Plane Congestion Information) from the RCAF to the PCRF. Any RUCI changes shall be reported by RCAF unless reporting restrictions apply.

Two types of messages are used on Np for transfer of congestion information from RCAF to PCRF:

– Non-aggregated RUCI report messages, which are sent on a per UE per APN basis using DRA routing. The IMSI and the APN can be used to route messages.

– Aggregated RUCI report messages, which are sent between an RCAF and PCRF and contain congestion information for multiple UEs. A logical PCRF id is allocated for these aggregate messages which determine the destination of the message.

The congestion reporting takes place as shown in Figure 7.10.1 below.

Figure 7.10.1: RUCI reporting from RCAF to PCRF

1. RCAF indicates congestion information for a given UE and APN in a RUCI report message. This message is routed by DRA to the appropriate PCRF based on IMSI and APN.

The RUCI report message includes the RUCI which is defined in clause 6.1.15.1.

Upon receiving the RUCI the PCRF stores the identity of the RCAF for the given UE if the RUCI indicates congestion. The PCRF makes a policy decision.

2. The PCRF allocates a logical PCRF id to identify the PCRF that is the Np destination for the given UE and APN for the RCAF when sending aggregate messages, and reports the logical PCRF id in the RUCI acknowledgement.

The RCAF stores the logical PCRF id in the UE context for the given IMSI, APN combination.

3. Subsequent congestion information for the given UE can be sent as part of an Aggregated RUCI report message. Such a message can contain the congestion information for multiple UEs. These UEs can have different congestion levels associated with different eNB identifier or ECGI or SAI, which are indicated in the message. An aggregated RUCI report message is always destined to a single PCRF only, and can be routed directly to that PCRF or via the DRA.

NOTE: How the RCAF decides about which information should be contained in a single aggregated RUCI report message out of the UEs with a given logical PCRF id is out of the scope of 3GPP specifications. e.g. the RCAF may aggregate information only for a given cell or eNB into a single message. Alternatively, the RCAF may wait for a configurable period of time to aggregate information from multiple cells or eNBs into a single message. The amount of RUCI updates may be limited by configuring a minimum time between RUCI updates in the RCAF (e.g. when only the identifier of the congested cell serving the UE has changed). This configuration is expected to take both the required accuracy as well as the acceptable signalling amount into account.

4. The Aggregated RUCI is acknowledged.

7.10.2 PCRF provided reporting restrictions

This clause describes the signalling flow for adding, updating or removing reporting restrictions for a given UE and APN. A pre-condition for this procedure is that the RCAF has already performed RUCI reporting for the given UE and APN. The PCRF stores the RCAF identity for the given UE when the RCAF performs RUCI reporting indicating congestion

This procedure may be triggered by the initial RUCI report message for the given UE at an RCAF, or by other events, e.g., change in the subscription. The procedure is shown in Figure 7.10.2 below.

Figure 7.10.2: PCRF provided reporting restrictions

1. PCRF sends a Modify UE context request to the RCAF of the given UE and APN using the stored identity of the RCAF, specifying the new reporting restrictions or the removal of the reporting restrictions. The RCAF stores the new reporting restrictions or removes the reporting restrictions accordingly.

2. The RCAF sends a Modify UE context response back to the PCRF to notify the PCRF about the success of the change in the reporting restrictions.

3. In case the RCAF already had reporting restrictions for the UE and the APN which are changed in step 2, this may trigger RUCI reporting as specified in clause 7.10.1. This occurs in case of a change from disabled reporting to enabled reporting, or if some reporting restrictions are lifted. The RCAF uses the RUCI report message to report congestion information to the PCRF if it is allowed by the change in the reporting restrictions.

4. The RUCI is acknowledged.

7.10.3 UE mobility between RCAFs

This clause describes the handling mobility of a UE from one RCAF to a different RCAF. The PCRF applies the rules described in clause 6.1.15.3.

The process is shown in Figure 7.10.3 below for the case when the UE is affected by congestion at RCAF2 after the UE was earlier affected by congestion at RCAF1.

Figure 7.10.3: UE mobility from RCAF1 to RCAF2 in case UE is affected by congestion at RCAF2 after the UE was earlier affected by congestion at RCAF1

1. RCAF1 reports RAN user plane congestion information (RUCI). The PCRF stores the identity of the current RCAF1 for a given UE when it receives the congestion information over Np that is different from no congestion.

2. The RUCI is acknowledged.

3. The UE moves to RCAF2 where it is affected by congestion. RCAF2 reports RAN user plane congestion information (RUCI). The PCRF stores the identity of the current RCAF2 for the given UE when it receives the congestion information over Np that is different from no congestion.

4. The RUCI is acknowledged.

5. Using on the previously stored identity of the old RCAF, the PCRF sends a Release context request message to RCAF1.

6. RCAF1 acknowledges this by sending the Release context response message to the PCRF. The RCAF releases the context corresponding to the given UE and given APN, including any reporting restrictions. This also implies that the RCAF does not indicate to the PCRF that the congestion state is over. In case of multiple PCRFs being in simultaneous use for a given UE, a Release context request message from a PCRF applies to the given Np connection only identified by the APN. The RCAF can completely release all context information for a given UE when it has released the context for each Np connection of the given UE.