7.3d Transmission using PUR

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.3d.1 General

Transmission using PUR allows one uplink transmission from RRC_IDLE using a preconfigured uplink resource without performing the random access procedure.

Transmission using PUR is enabled by the (ng-)eNB if the UE and the (ng-)eNB support.

The UE may request to be configured with a PUR or to have a PUR configuration released while in RRC_CONNECTED mode. The (ng-)eNB decides to configure a PUR that may be based on UE’s request, UE’s subscription information and/or local policy. The PUR is only valid in the cell where the configuration was received.

Transmission using PUR is triggered when the upper layers request the establishment or resumption of the RRC Connection and the UE has a valid PUR for transmission and meets the TA validation criteria as specified in TS 36.331 [16].

Transmission using PUR is only applicable to BL UEs, UEs in enhanced coverage and NB-IoT UEs.

7.3d.2 PUR Configuration Request and PUR configuration

The procedure for PUR configuration request and PUR configuration is common to the Control Plane CIoT EPS/5GS optimisations and the User Plane CIoT EPS/5GS optimisations and is illustrated in Figure 7.3d-1.

Figure 7.3d-1: PUR Configuration Request and PUR Configuration

0. The UE is in RRC_CONNECTED and PUR is enabled in the cell.

1. The UE may indicate to the (ng-)eNB that it is interested in being configured with PUR by sending PURConfigurationRequest message providing information about the requested resource (e.g. No. of occurences, periodicity, time offset, TBS, RRC Ack, etc.). Alternatively, the UE may indicate to the (ng-)eNB in the PURConfigurationRequest message that it is interested in the configured PUR to be released.

2. When the (ng-)eNB moves the UE to RRC_IDLE, based on a precedent UE PUR configuration request, subscription information and/or local policies, the (ng-)eNB may decide to provide a PUR resource to the UE or to release an existing PUR resource. The (ng-)eNB includes the details of the PUR configuration or a PUR release indication in the RRCConnectionRelease message.

For UEs using the Control Plane CIoT EPS/5GS optimisations, the (ng-)eNB may provide a PUR configuration ID with the PUR configuration. If available, the UE includes the PUR configuration ID in RRCConnectionSetupComplete message when establishing RRC connection(s) not using the PUR resource.

NOTE 1: The PUR configuration can be implicitly released at the UE and (ng-)eNB, when the UE accesses in another cell, when PUR is no longer enabled in the cell, or when the PUR resource has not been used for a configured number of consecutive occasions.

NOTE 2: It is up to (ng-)eNB implementation how UE and PUR configuration are linked according to the configured PUR resources.

7.3d.3 Transmission using PUR for Control Plane CIoT EPS/5GS Optimisations

Transmission using PUR for Control Plane CIoT EPS Optimisation, as defined in TS 24.301 [20], and for Control Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91], is characterised as below:

– Uplink user data are transmitted using the PUR resource in a NAS message concatenated in RRCEarlyDataRequest message on CCCH;

– If there is no downlink data, the (ng-)eNB may terminate the procedure by sending a layer 1 acknowledgement optionally containing a Time Advance Command, a MAC Time advance Command or RRCEarlyDataComplete with no user data;

– Downlink user data, if any, are transmitted in a NAS message concatenated in RRCEarlyDataComplete message on CCCH;

– There is no transition to RRC CONNECTED.

The procedure for transmission using PUR for the Control Plane CIoT EPS optimisation and for the Control Plane CIoT 5GS optimisation is illustrated in Figure 7.3d-2.

Figure 7.3d-2: Transmission using PUR for the Control Plane CIoT EPS/5GS Optimisations

0. The UE has determined that the PUR resource can be used (e.g. PUR enabled in the cell, valid Time Alignment, etc.).

1 Same as step 1 in MO-EDT for Control Plane CIoT EPS/5GS optimisations in Figure 7.3b-1 and 7.3b-1a except that the UE transmits over the PUR resource instead of a resource allocated in the random access response.

If the uplink data are too large to be included in RRCEarlyDataRequest, the UE can use the PUR resource to transmit RRCConnectionRequest. The procedure will fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned.

After step 1, the (ng-)eNB may request the UE to abort the transmission using PUR by sending a Layer 1 fallback indication. UE actions upon reception of Layer 1 fallback indication are left up to UE implementation.

2..6 Same as MO-EDT for Control Plane CIoT EPS/5GS Optimisations in Figure 7.3b-1 and 7.3b-1a.

7a If the (ng-)eNB is aware that there is no pending downlink data or signalling, the (ng-)eNB can send a Layer 1 ACK optionally containing a Time Advance Adjustment to the UE to update the TA and terminate the procedure.

7b If the (ng-)eNB is aware that there is no further data or signalling, the (ng-)eNB can send a Time Advance Command to update the TA and terminate the procedure.

7c Same as step 7 in MO-EDT for Control Plane CIoT EPS/5GS Optimisations in Figure 7.3b-1 and 7.3b-1a except that a Time Advance Command can also be included.

NOTE 1: If the MME/AMF or the (ng-)eNB decides to move the UE to RRC_CONNECTED mode, RRCConnectionSetup message is sent in step 7 to fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned. The (ng-)eNB will discard the zero-length NAS PDU received in RRCConnectionSetupComplete message.

NOTE 2: If none of Layer 1 Ack, MAC Time advance Command, RRCEarlyDataComplete and, in case of fallback, RRCConnectionSetup is received in response to RRCEarlyDataRequest, the UE considers the UL data transmission not successful.

7.3d.4 Transmission using PUR for User Plane CIoT EPS/5GS Optimisations

Transmission using PUR for User Plane CIoT EPS Optimisation, as defined in TS 24.301 [20], and for User Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91], are characterised as below:

– The UE is in RRC_IDLE and has a valid PUR resource;

– The UE has been provided with a NextHopChainingCount in the RRCConnectionRelease message with suspend indication;

– Uplink user data are transmitted on DTCH multiplexed with RRCConnectionResumeRequest message on CCCH;

– Downlink user data are optionally transmitted on DTCH multiplexed with RRCConnectionRelease message on DCCH;

– The user data in uplink and downlink are ciphered. The keys are derived using the NextHopChainingCount provided in the RRCConnectionRelease message of the previous RRC connection;

– The RRCConnectionRelease message is integrity protected and ciphered using the newly derived keys;

– There is no transition to RRC CONNECTED.

The procedure for transmission using PUR for the User Plane CIoT EPS optimisation and for the User Plane CIoT 5GS optimisation is illustrated in Figure 7.3d-3 and Figure 7.3d-4 respectively.

Figure 7.3d-3: Transmission using PUR for the User Plane CIoT EPS Optimisation

Figure 7.3d-4: Transmission using PUR for the User Plane CIoT 5GS Optimisation

0. The UE has validated the PUR resource according to the configured criteria.

1 Same as step 1 in MO-EDT for User Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a except that the UE transmits over the PUR resource instead of a resource allocated in the random access response.

If the user data are too large to be fully included in the transmission using PUR, the UE can use PUR to transmit RRCConnectionResumeRequest and a segment of the user data. The procedure will fall back to the legacy RRC Connection Resume procedure; a new C-RNTI can be assigned.

2..7 Same as MO-EDT for User Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a.

8 Same as step 8 in MO-EDT for user Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a except that a Time Advance Command can also be included.

NOTE 1: If the MME/AMF or the (ng-)eNB decides to move the UE to RRC_CONNECTED mode, RRCConnectionResume message is sent in step 8 to fall back to the RRC Connection resume procedure. In that case, the RRCConnectionResume message is integrity protected and ciphered with the keys derived in step 1 and the UE ignores the NextHopChainingCount included in the RRCConnectionResume message; a new C-RNTI can be assigned. Downlink data can be transmitted on DTCH multiplexed with the RRCConnectionResume message. In addition, an RRCConnectionSetup can also be sent in step 8 to fall back to the RRC Connection establishment procedure.

NOTE 2: If neither RRCConnectionRelease nor, in case of fallback, RRCConnectionResume is received in response to RRCConnectionResumeRequest using PUR, the UE considers the UL data transmission not successful.