18 Small Data Transmission
38.3003GPPNRNR and NG-RAN Overall descriptionRelease 17Stage 2TS
18.0 General
Small Data Transmission (SDT) is a procedure allowing data and/or signalling transmission while remaining in RRC_INACTIVE state (i.e. without transitioning to RRC_CONNECTED state). SDT is enabled on a radio bearer basis and is initiated by the UE only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled, the DL RSRP is above a configured threshold, and a valid SDT resource is available as specified in clause 5.27.1 of TS 38.321 [6].
SDT procedure is initiated with either a transmission over RACH (configured via system information) or over Type 1 CG resources (configured via dedicated signalling in RRCRelease). The SDT resources can be configured on initial BWP for both RACH and CG. RACH and CG resources for SDT can be configured on either or both of NUL and SUL carriers. The CG resources for SDT are valid only within the PCell of the UE when the RRCRelease with suspend indication is received. CG resources are associated with one or multiple SSB(s). For RACH, the network can configure 2-step and/or 4-step RA resources for SDT. When both 2-step and 4-step RA resources for SDT are configured, the UE selects the RA type according to clause 9.2.6. CFRA is not supported for SDT over RACH.
Once initiated, the SDT procedure is either:
– successfully completed after the UE is directed to RRC_IDLE (via RRCRelease) or to continue in RRC_INACTIVE (via RRCRelease or RRCReject) or to RRC_CONNECTED (via RRCResume or RRCSetup); or
– unsuccessfully completed upon cell re-selection, expiry of the SDT failure detection timer, a MAC entity reaching a configured maximum PRACH preamble transmission threshold, an RLC entity reaching a configured maximum retransmission threshold, or expiry of SDT-specific timing alignment timer while SDT procedure is ongoing over CG and the UE has not received a response from the network after the initial PUSCH transmission.
Upon unsuccessful completion of the SDT procedure, the UE transitions to RRC_IDLE.
The initial PUSCH transmission during the SDT procedure includes at least the CCCH message. When using CG resources for initial SDT transmission, the UE can perform autonomous retransmission of the initial transmission if the UE does not receive confirmation from the network (dynamic UL grant or DL assignment) before a configured timer expires as specified in clause 5.4.1 of TS 38.321 [6]. After the initial PUSCH transmission, subsequent transmissions are handled differently depending on the type of resource used to initiate the SDT procedure:
– When using CG resources, the network can schedule subsequent UL transmissions using dynamic grants or they can take place on the following CG resource occasions. The DL transmissions are scheduled using dynamic assignments. The UE can initiate subsequent UL transmission only after reception of confirmation (dynamic UL grant or DL assignment) for the initial PUSCH transmission from the network. For subsequent UL transmission, the UE cannot initiate re-transmission over a CG resource.
– When using RACH resources, the network can schedule subsequent UL and DL transmissions using dynamic UL grants and DL assignments, respectively, after the completion of the RA procedure.
While the SDT procedure is ongoing, if data appears in a buffer of any radio bearer not enabled for SDT, the UE initiates a transmission of a non-SDT data arrival indication using UEAssistanceInformation message to the network and, if available, includes the resume cause.
SDT procedure over CG resources can only be initiated with valid UL timing alignment. The UL timing alignment is maintained by the UE based on a SDT-specific timing alignment timer configured by the network via dedicated signalling and, for initial CG-SDT transmission, also by DL RSRP of configured number of highest ranked SSBs which are above a configured RSRP threshold. Upon expiry of the SDT-specific timing alignment timer, the CG resources are released while maintaining the CG resource configuration.
Logical channel restrictions configured by the network while in RRC_CONNECTED state and/or in RRCRelease message for radio bearers enabled for SDT, if any, are applied by the UE during SDT procedure.
The network may configure UE to apply ROHC continuity for SDT either when the UE initiates SDT in the PCell of the UE when the RRCRelease with suspend indication was received or when the UE initiates SDT in a cell of its RNA.
18.1 Support of SDT procedure over RACH
For SDT procedure over RACH, if the UE accesses a gNB other than the last serving gNB, the UL SDT data/signalling is buffered at the receiving gNB, and then the receiving gNB triggers the XnAP Retrieve UE Context procedure. The receiving gNB indicates SDT to the last serving gNB and the last serving gNB decides whether to relocate the UE context or not. Other SDT assistance information (e.g., single packet, multiple packets) may also be provided by the receiving gNB to help the decision of UE context relocation.
If the last serving gNB decides not to relocate the full UE context, it transfers a partial UE context containing SDT RLC context information necessary for the receiving gNB to handle SDT via the Partial UE Context Transfer procedure.
Then, in case SDT is used for user data over DRBs, UL/DL tunnels are established for DRBs configured for SDT between the receiving gNB and the last serving gNB. The PDCP PDU of UL/DL data is transferred over the tunnels, until the last serving gNB terminates the SDT session and directs the UE to continue in RRC_INACTIVE by sending the RRCRelease message.
Or in case SDT is used for signalling, SRB PDCP PDUs are transferred between the receiving gNB and the last serving gNB via the XnAP RRC Transfer procedure, until the last serving gNB terminates the SDT session and directs the UE to continue in RRC_INACTIVE by sending the RRCRelease message.
During the SDT session, in case the receiving gNB detects that no more packets are to be transmitted, or radio link problem is detected, the receiving gNB may also request to terminate the SDT session to the last serving gNB via the UE Context Retrieve Confirmation procedure.
18.2 SDT with UE context relocation
The overall procedure for SDT procedure over RACH with UE context relocation is illustrated in the figure 18.2-1.
Figure 18.2-1. RA-based SDT with UE context relocation
1. The UE sends an RRCResumeRequest as well as UL SDT data and/or UL SDT signalling to the receiving gNB.
2. The receiving gNB identifies the last serving gNB using the I-RNTI and retrieves the UE context by means of Xn-AP Retrieve UE Context procedure. The receiving gNB indicates that the UE request is for an SDT and may also provide SDT assistance information (e.g., single packet, multiple packets).
3. The last serving gNB decides to relocate UE context and responds with the RETRIEVE UE CONTEXT RESPONSE message. The UL SDT data, if any, is delivered from the receiving gNB to the UPF.
4-6. The receiving gNB decides to keep UE in RRC_INACTIVE state for SDT. If loss of DL user data buffered in the last serving gNB shall be prevented, the receiving gNB provides forwarding addresses via the Xn-U ADDRESS INDICATION message. The receiving gNB also initiates NG-AP Path Switch procedure to establish a NG UE associated signalling connection to the serving AMF. After the Path Switch procedure, the buffered UL NAS PDU, if any, is delivered from the receiving gNB to the AMF. And then, the subsequent UL/DL SDT data and/or signalling are transferred between UE and core network via the receiving gNB.
7. After the SDT transmission is completed, the receiving gNB generates and sends the RRCRelease message including the suspend indication to the UE to complete the SDT procedure and continue in RRC_INACTIVE state.
NOTE: In case DL non-SDT data or DL non-SDT signalling arrives, or the UE assistance information (i.e. UL non-SDT data arrival indication) is received from the UE, the receiving gNB may decide to directly send the UE to RRC_CONNECTED state by sending the RRCResume message.
8. The receiving gNB indicates to the last serving gNB to remove the UE context by sending the XnAP UE CONTEXT RELEASE message. The XnAP UE CONTEXT RELEASE message can be sent after step 6.
18.3 SDT without UE context relocation
The overall procedure for SDT procedure over RACH without UE context relocation is illustrated in the figure 18.3-1.
Figure 18.3-1. RA-based SDT without UE context relocation
1/2. The steps 1/2 are as defined in steps 1/2 in Figure 18.2-1.
3. The last serving gNB decides not to relocate the full UE context for SDT.
4. The last serving gNB transfers a partial UE context including the SDT related RLC context.
5. The receiving gNB acknowledges receiving the partial UE context and provides associated DL TNL address. The UE context is kept at the last serving gNB and the SDT related RLC context is established at the receiving gNB. Then UL/DL GTP-U tunnels are established for DRBs configured for SDT, if any, and the UL SDT data and/or signalling, if any, are forwarded to the last serving gNB, and then delivered to the core network.
NOTE 1: The DL signalling from the last serving gNB, if any, is forwarded to the receiving gNB via the RRC TRANSFER message, for which the receiving gNB delivers it to the UE.
6. The receiving gNB detects the end of SDT session and sends the RETRIEVE UE CONTEXT CONFIRM message including whether this is a "normal" end of SDT transaction or a radio link problem.
7. Upon receiving the RETRIEVE UE CONTEXT CONFIRM message and deciding to terminate the SDT, the last serving gNB responds to the receiving gNB with the RETRIEVE UE CONTEXT FAILURE message including an encapsulated RRCRelease message. The receiving gNB shall release the established partial UE context.
NOTE 2: Void..
NOTE 3: Void..
8. The receiving gNB sends the RRCRelease message to the UE.
NOTE 4: In case DL non-SDT data or DL non-SDT signalling arrives, or receives UE assistance information (i.e. UL non-SDT data arrival indication) from the UE, the last serving gNB completes the SDT procedure and directs the UE to continue in RRC_INACTIVE state by sending the RRCRelease message.
9. The UE moves to RRC_INACTIVE state if the suspend indication is included in the RRCRelease message. Or else, the UE moves to RRC_IDLE state.