8.2.8 PUSCH capacity request [TDD only]

25.3313GPPProtocol specificationRadio Resource Control (RRC)Release 17TS

Figure 8.2.8-1: PUSCH Capacity request procedure

8.2.8.1 General

With this procedure, the UE transmits its request for PUSCH resources to the UTRAN. In the normal case, the UTRAN responds with a PHYSICAL SHARED CHANNEL ALLOCATION message, which either allocates the requested PUSCH resources, and/or allocates a PDSCH resource, or may just serve as an acknowledgement, indicating that PUSCH allocation is pending.

This procedure can also be used to acknowledge the reception of a PHYSICAL SHARED CHANNEL ALLOCATION message, or to indicate a protocol error in that message.

With the PUSCH CAPACITY REQUEST message, the UE can request capacity for one or more USCH.

8.2.8.2 Initiation

This procedure is initiated:

1> in the CELL_FACH or CELL_DCH state;

1> and when at least one RB using USCH has been established;

1> and when the UE sees the requirement to request physical resources (PUSCH) for an USCH channel or there is the need to reply to a PHYSICAL SHARED CHANNEL ALLOCATION message as described in clause 8.2.7 (i.e. to confirm the reception of a message, if requested to do so, or to indicate a protocol error).

The procedure can be initiated if:

– Timer T311 is not running.

– The timer T310 (capacity request repetition timer) is not running.

The UE shall:

1> set the IEs in the PUSCH CAPACITY REQUEST message according to subclause 8.2.8.3;

1> if the procedure is triggered to reply to a previous PHYSICAL SHARED CHANNEL ALLOCATION message by the IE "Confirm request" set to "Confirm PUSCH" and the IE "PUSCH capacity allocation info" is not present:

2> transmit the PUSCH CAPACITY REQUEST message on RACH.

1> else:

2> transmit the PUSCH CAPACITY REQUEST message on the uplink SHCCH.

1> set counter V310 to 1;

1> start timer T310.

8.2.8.3 PUSCH CAPACITY REQUEST message contents to set

With one PUSCH CAPACITY REQUEST message, capacity for one or more USCH can be requested. It shall include these information elements:

1> DSCH-RNTI to be used as UE identity if the message is sent on RACH;

1> Traffic volume measured results for each radio bearer satisfying the reporting criteria as specified in the MEASUREMENT CONTROL procedure (if no radio bearer satisfies the reporting criteria, traffic volume measured results shall not be included). These results shall include:

2> Radio Bearer ID of the Radio Bearer being reported;

2> RLC buffer payload for these radio bearers, as specified by the MEASUREMENT CONTROL procedure.

The UE shall:

1> if the initiation of the procedure is triggered by the IE "Traffic volume report request" in a previously received PHYSICAL SHARED CHANNEL ALLOCATION message:

2> report the traffic volume measurement result for the radio bearer mapped on USCH transport channel specified in the received message. These results shall include:

3> Radio Bearer ID of the Radio Bearer being reported;

3> RLC buffer payload for this radio bearer.

1> if the initiation of the procedure is triggered by the IE "Confirm request" set to "Confirm PDSCH" in a previously received PHYSICAL SHARED CHANNEL ALLOCATION message and the IE "PUSCH capacity allocation info" is present in this message:

2> set the CHOICE "Allocation confirmation" to "PDSCH Confirmation" with the value given in the IE "PDSCH Identity" stored in the variable PHYSICAL_SHARED_CHANNEL_CONFIGURATION.

1> if the initiation of the procedure is triggered by the IE "Confirm request" set to "Confirm PUSCH" in a previously received PHYSICAL SHARED CHANNEL ALLOCATION message:

2> set the CHOICE "Allocation confirmation" to "PUSCH Confirmation" with the value given in the IE "PUSCH Identity" stored in the variable PHYSICAL_SHARED_CHANNEL_CONFIGURATION.

1> if the variable PROTOCOL_ERROR_REJECT is set to TRUE:

2> include the IE "RRC transaction identifier" in the response message transmitted below; and

2> set it to the value of "RRC transaction identifier" in the entry for the PHYSICAL SHARED CHANNEL ALLOCATION message in the table "Rejected transactions" in the variable TRANSACTIONS; and

2> clear that entry;

2> set the IE "protocol error indicator" to TRUE;

2> include the IE "Protocol error information" with contents set to the value of the variable PROTOCOL_ERROR_INFORMATION.

1> if the value of the variable PROTOCOL_ERROR_ REJECT is FALSE:

2> set the IE "Protocol error indicator" to FALSE.

As an option, the message may include IE "Timeslot ISCP" and IE "Primary CCPCH RSCP".

The timeslots for which "Timeslot ISCP" may be reported shall have been configured with a previous PHYSICAL SHARED CHANNEL ALLOCATION message and stored in the variable PHYSICAL_SHARED_CHANNEL_CONFIGURATION.

"Primary CCPCH RSCP" is reported when requested with a previous PHYSICAL SHARED CHANNEL ALLOCATION message.

8.2.8.4 Reception of a PUSCH CAPACITY REQUEST message by the UTRAN

Upon receiving a PUSCH CAPACITY REQUEST message with traffic volume measurement included for at least one radio bearer, the UTRAN should initiate the PHYSICAL SHARED CHANNEL ALLOCATION procedure, either for allocating PUSCH or PDSCH resources as required, or just as an acknowledgement, indicating a pending PUSCH allocation, as described in subclause 8.2.7.

8.2.8.5 T310 expiry

Upon expiry of timer T310, the UE shall:

1> if V310 is smaller than N310:

2> transmit a new PUSCH CAPACITY REQUEST message on the Uplink SHCCH;

2> restart timer T310;

2> increment counter V310;

2> set the IEs in the PUSCH CAPACITY REQUEST message as specified in subclause 8.2.8.3.

1> if V310 is greater than or equal to N310:

2> the procedure ends.