Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  18.1.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.2.5…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.2…   16.3…   16.4…   16.8…   16.9…   16.10…   16.12…   16.12.5…   16.12.6…   16.12.6.3   16.12.7   16.13…   16.14…   16.15…   16.18…   16.19…   16.21…   16.21.3…   17…   18…   19   20…   21…   A…   B…   C…   G…

 

18  Small Data Transmission |R17|p. 230

18.0  Generalp. 230

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 can be initiated either by the UE in case of MO-SDT (Mobile Originated SDT) or by the network in case of MT-SDT (Mobile Terminated SDT). MO-SDT is initiated by the UE only if less than or equal to 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. MT-SDT is initiated by the network with an indication to the UE in a paging message when DL data awaits transmission for radio bearers configured for SDT; based on the indication, the UE initiates the MT-SDT only if the DL RSRP is above a configured threshold as specified in clause 5.27.1 of TS 38.321. When MT-SDT is initiated by the UE, a resume cause indicating MT-SDT is included in the RRCResumeRequest / RRCResumeRequest1. Maximum duration the SDT procedure can last is dictated by a SDT failure detection timer that is configured by the network (see clause 6.2.2 of TS 38.331). Network can enable MO-SDT, MT-SDT, or both in a cell.
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 MO-SDT. When both 2-step and 4-step RA resources for MO-SDT are configured, the UE selects the RA type according to clause 9.2.6. If MT-SDT procedure is initiated over RACH, only the RACH resources not configured for SDT can be used by the UE. 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 integrity check failure while SDT procedure is ongoing, or expiry of SDT-specific timing alignment timer or configuredGrantTimer 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.
For SDT, network should not send RRCReject in response to RRCResumeRequest / RRCResumeRequest1 if DL data over any radio bearer configured for SDT is transmitted.
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. 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.
When SDT procedure is initiated, AS security is applied for all the radio bearers enabled for SDT as specified in clause 5.3.13.3 of TS 38.331.
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.
While the SDT procedure is ongoing and RA procedure is triggered (e.g., upon UL data arrival as specified in clause 9.2.6), only the RACH resources not configured for SDT can be used by the UE.
The network may initiate transmission of RRCRelease message with resumeIndication for the UE to trigger RRC resume procedure after the cell selection.
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.
For SDT procedure over CG resources, the network may configure maximum time duration until the next valid CG occasion for initial CG-SDT transmission based on which the UE decides whether SDT procedure over CG resources can be initiated. The maximum time duration is configured per logical channel for MO-SDT and per UE for MT-SDT.
Up

18.1  Support of SDT procedure over RACHp. 232

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 UE is configured with the clock quality control information, the last serving gNB performs full UE context relocation to enable the receiving gNB to provide clock quality information.
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.
Up

18.2  SDT with UE context relocationp. 232

The overall procedure for SDT procedure over RACH with UE context relocation is illustrated in the Figure 18.2-1.
Reproduction of 3GPP TS 38.300, Fig. 18.2-1: RA-based SDT with UE context relocation
Up
Step 1.
The UE sends an RRCResumeRequest as well as UL SDT data and/or UL SDT signalling to the Receiving gNB.
Step 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).
Step 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.
Step 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 NGAP Path Switch Request procedure to establish a NG UE-associated signalling connection to the AMF. After the Path Switch Request 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.
Step 7.
After the SDT transmission is terminated, the Receiving gNB generates and sends the RRCRelease message including the suspend indication to the UE to terminate the SDT procedure and continue in RRC_INACTIVE state.
Step 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.
Up

18.3  SDT without UE context relocationp. 234

The overall procedure for SDT procedure over RACH without UE context relocation is illustrated in the Figure 18.3-1.
Reproduction of 3GPP TS 38.300, Fig. 18.3-1: RA-based SDT without UE context relocation
Up
Step 1/2.
The steps 1/2 are as defined in steps 1/2 in Figure 18.2-1.
Step 3.
The last serving gNB decides not to relocate the full UE context for SDT.
Step 4.
The last serving gNB transfers a partial UE context including the SDT related RLC context.
Step 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.
Step 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, or large SDT volume from BSR.
Step 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.
Step 8.
The receiving gNB sends the RRCRelease message to the UE.
Step 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.
Up

18.4  MT-SDT with/without UE context relocation |R18|p. 235

The overall procedure for MT-SDT procedure with/without UE context relocation is illustrated in the Figure 18.4-1.
Reproduction of 3GPP TS 38.300, Fig. 18.4-1: MT-SDT with/without UE context relocation
Up
Step 1.
DL user data and/or DL NAS signalling are received at the Last Serving gNB for the UE in RRC_INACTIVE state, or RAN Paging request message is received at the Last Serving gNB for the UE in RRC_INACTIVE state with long eDRX(cycle) beyond 10.24 seconds.
Step 2.
The Last Serving gNB may send MT-SDT information to the neighbour gNBs within the RNA, via XnAP RAN PAGING message.
Step 3.
The gNB that receives MT-SDT information within the RNA, takes into account the MT-SDT information received in the XnAP RAN PAGING message to decide whether to trigger MT-SDT Paging. The gNB which ultimately reaches the UE via the Uu Paging becomes the Receiving gNB.
Step 4/5.
The UE may decide to initiate MT-SDT procedure and in this case sends an RRCResumeRequest message with an MT-SDT resume cause to the Receiving gNB.
Step 6.
The following steps are the same as Figure 18.2-1 / Figure 18.3-1 from step 2, except that the first SDT user data and/or NAS signalling is DL SDT data and/or DL SDT NAS signalling.
Up

Up   Top   ToC