Small Data Transmission (二)具体过程

已于 2024-10-01 16:27:07 修改
阅读量1.3k 收藏
点赞数
分类专栏： NR R16 R17 文章标签： 5G
于 2023-11-30 17:01:21 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/asd199086/article/details/134716661
版权
NR R16 R17 专栏收录该内容
37 篇文章 ¥199.90 ¥299.90
订阅专栏
本文深入探讨了5G NR中CG-SDT（Configured Grant Single Data Transmission）的具体过程，包括RRC层的初始化条件、MAC层的判断逻辑、TA验证、路径损耗参考推导等关键环节，详细阐述了CG-SDT在RRC INACTIVE状态下的传输流程，是理解5G数据传输机制的重要参考资料。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 

 

这篇是SDT相关的具体过程，包括RRC层初始化SDT 的条件，MAC 层初始化SDT过程的判断，CG-SDT的具体过程，TA Validation for CG-SDT， CG-SDT TA 验证的路径损耗参考推导，SDT Uplink Time Alignment，RRC inactive中的CG based PUSCH传输和RA based PUSCH传输，依次看下。

初始化SDT的条件(38.331) 

5f7dd1e42f46e3cf4005c4cdd227df3f.png

当满足以下所有条件时，RRC_INACTIVE中的UE就会发起SDT的resume过程：

(1)上层请求恢复RRC连接； 

(2)SIB1包括sdt-ConfigCommon； 

(3)sdt-Config配置完毕； 

(4)UL中的所有待处理数据有映射到为SDT配置的RB； 

(5)对于RedCap UE，当RedCap specific initial DL BWP不包括CD-SSB时，有配置ncd-SSB-RedCapInitialBWP-SDT

了解本专栏 订阅专栏 解锁全文
Small Data Transmission(一) overview
asd199086的博客
11-30 1766
在回复UE恢复RRC连接的请求或为SDT发起的恢复过程时，网络可以恢复suspend的RRC连接并让UE进入RRC_CONNECTED，也可以拒绝恢复请求并让UE继续在RRC_INACTIVE(使用wait timer)，亦或直接重新suspend RRC连接并让UE待在RRC_INACTIVE，还可以直接释放RRC连接并将UE进入RRC_IDLE，最后还可以指示UE发起NAS级别恢复(在这种情况下，网络会发送RRC setup消息)。对于后续的UL传输，UE无法通过CG资源发起重传。
Small Data Transmission(三) 具体过程 part two
ModemProtocol的博客
10-04 255
sdt-SearchSpace的配置路径如上图，PDCCH-ConfigCommon->sdt-SearchSpace，sdt-SearchSpace配置对应的是Type1A-PDCCH CSS set，用于Pcell上C-RNTI或CS-RNTI 加扰的CRC的DCI format的传输。如上图是CG-SDT配置的SSB结构图，主要与sdt-SSB-Subset有关系，sdt-SSB-Subset配置结构和SIB1中的ssb-PositionsInBurst一样，且是其子集。，以进行PDSCH接收。
3GPP Rel-17 可能要立项的课题 (NR light, Small data, Multi sim, 52.6G)
Wei Xingguang
07-14 3760
在3GPPRAN#84次会议上，各个通信公司发表了各自对于Rel-17立项的观点。经过激烈的讨论后，大家提取出较多公司支持的立项进行下一步的邮件讨论。 下面把RAN主席总结的Rel-17可能的立项信息（参考RP-191551）总结如下，供大家查阅。 目录 [NR_Light] (moderator: Ericsson) [Small_data] (moderator: ZTE) [S...
Redcap UE的BWP Operation
asd199086的博客
01-17 3009
如果没有配置initialDownlinkBWP-RedCap，就应用initialDownlinkBWP，但是配置时，要符合RedCap UE的最大带宽要求，不能超过RedCap UE的能力。可能有人对于NCD-SSB的含义不太清楚，这里简单说明下，CD-SSB就是指有关联RMSI(SIB1)的SSB，即在小区搜索过程中通过SSB带的COREST0 去接收RMSI，如果SSB没有带CORESET0，UE就无法接收SIB1，这样的SSB就叫NCD-SSB。Redcap UE配置NCD-SSB的路径如上。
Small Data Transmission(二) 具体过程 part one
ModemProtocol的博客
10-04 246
1 如果UE有进行带有CCCH消息的CG-SDT的初始传输之后，但是还没有收到C-RNTI加扰的PDCCH，此时要进行CG-SDT初始传输的重传，如果用于重传的configured UL grant对应的SSB与CG-SDT的初始传输的SSB相同，就选择该SSB，向下层指示configured UL grant对应的SSB index，并认为当前配置的configured UL grant有效。对于CG-SDT有2个RRC配置需要注意，cg-SDT-CS-RNTI代表用于CG-SDT重传的CS-RNTI；
R17 redcap深度解析
asd199086的博客
11-16 5829
在5G时代，某些场景的终端并不需要特别复杂，只要满足成本低，功耗小，尺寸小等要求即可，例如视频监控，可穿戴设备，工业无线传感器等，redcap就是在这样的背景下提出的。目前的大环境下，3GPP R17 redcap标准已经冻结，华为，中兴，爱立信，vivo，诺基亚贝尔等厂家已经完成关键技术及外场验证测试，R17 redcap商用基本没有悬念。但是到底什么是redcap UE？其工作机制又是怎样的？这里我们一步步来看下。Redcap的内容分散在38.300/38.306/38.331/38.321等spec中
5G NR Positioning enhancement (R17)
一个关于5G NR的博客^^
10-12 4526
本篇介绍R17 Positioning enhancement，精度的提升(accuracy enhancement)延迟的减小(latency reduction)网络效率的提升(NW efficiency enhancement)UE效率的提升(device efficiency enhancement)这4点是整个enhancement的主旋律。
CD-SSB和NCD-SSB相关内容
asd199086的博客
11-11 1995
NR中，PSS/SSS 和PBCH总是绑定的，因此也称为SSB block。频域由下往上，第121个SC（k = 120）的中心频率，就是SSB的GSCN对应的SSREF（同步参考频率）的出处如上，同步栅格映射到SSB 的RE位置是10个PRB的位置，然后指向RE index 0，即第121个子载波的中心频率；UE获得N_offset_GSCN后，即可结合当前SSB的GSCN推算下一个SSB的GSCN =N_Reference_GSCN（当前SSB的GSCN） + N_offset_GSCN。
NR Channel raster和Sync raster
asd199086的博客
12-10 1324
NREF对应的就是NR ARFCN，RF 的参考频率就是FREF，两者的转换关系就是FREF = FREF-Offs + ΔFGlobal x ( NREF- NREF-Offs)。相似的，可用GSCN描述各个频带的同步信道。以第一区间0~3000MHZ为例，N=100,M=1,3,5 及N=101，M=1,3,5时 GSCN 与频率间的对应图如下，由公式也可以看出实际上N的频率变化稍大，而M是在N确定后进行的3小步频率上的微调，进而确定的GSCN与实际频率间的映射关系。
redcap preamble
5G砖家的博客
08-23 563
redcap preamble
NR协议UCI复用处理(二)：UCI传输的上行信道资源
m0_38043894的博客
09-13 3066
NR协议中SR、HARQ-ACK以及CSI report传输的上行信道资源
NR PUSCH(一)configured grant Type1 or Type 2
asd199086的博客
10-10 5395
先看38.214中的内容。PUSCH 可以由DCI 0_0/0_1/0_2动态调度，也可以根据是否有提前分配好UL grant的情况分为configured grant Type1 or Type 2 的传输。
NR C-DRX active Time包括哪些过程？
asd199086的博客
01-15 819
(2)inactivity-timer：UE等待成功解码PDCCH的持续时间，从PDCCH的最后一次成功解码开始，timer超时后UE可以返回sleep。(5)active-time：UE监听PDCCH的总时长。这包括 DRX cycle的 on-duration，在inactivity timer 未超时前 UE执行连续接收的时间以及 UE 在等待重传时机执行连续接收的时间。(1)正在运行的DRX group配置的drx-onDurationTimer或drx-InactivityTimer；
5G/NR Multiple SSBs的意义？
欢迎来到小七的博客，这里将带你深入探索5G通信的神秘世界。无论你是通信领域的专业人士还是对这一领域充满好奇心的技术爱好者，这里都有专业协议解读、通信知识普及以及有趣的Python编程内容等你发现。
07-02 4530
在一个载波中，只能在不同时隙同一频域上传输同一个SSB，还是可以不同时隙不同频域传输多个不同的SSB？答案是肯定的，gNB可以灵活配置时频域位置传输多个不同的SSB。SSB可以得到主同步信号(Primary Synchronization Signals, 简称PSS)、辅同步信号(Secondary Synchronization Signals, 简称SSS)以及PBCH，从而得到PCI以及MIB等重要信息，又从UE的角度来看，在每个服务小区中最多只能关联一个SSB。那么，在载波中的频域上传输多个不同的
5G NR SSB概述
热门推荐
小小小小怪的博客
02-03 5万+
       SSB（Synchronization Signal/PBCH, 同步广播块）是5G中使用的最重要的导频信道之一，其作用关系到UE接入小区的很多方面，如小区搜索、波束测量、波束选择、波束恢复等。 1、SSB时频域结构        在5G中，SSB包括同步信号和广播信号，具体同步信号包括PSS（Primary Synchronization Signal，
5G NR - 下行同步(DL Synchronization)学习笔记5 - SSB是否始终位于BWP之内？
yu_yuan_hong的专栏
12-08 3841
有同事问，SSB是否始终在BWP之内(频域)？ 当然不会,SSB中的B是Broadcast的意思，当然不是某个UE特有的。如《5G NR - 下行同步(DL Synchronization)学习笔记3 - SSB搜索过程》所述，基站会轮流在各波束方向发送SSB，某个波束底下可能会有一堆UEs接收，但是某个时刻各UE的BWP可能不相同，所以如果某个UE发生BWP切换，SSB始终保持不变(当然UE移动到另一个Beam下那是另外一回事)，处于InitialBWP之内。 一图胜千言 - 看图中橙色的SSB块和随
5G/NR同步信号之SSB概要
lilliana的博客
10-26 2万+
同步信号和PBCH块(Synchronization Signal and PBCH block, 简称SSB)，它由主同步信号(Primary Synchronization Signals, 简称PSS)、辅同步信号(Secondary Synchronization Signals, 简称SSS)、PBCH三部分共同组成。 SSB时域上共占用4个OFDM符号，频域共占用240个子载波(20个PRB)，编号为0~239，如图1所示。 ...
Payload Form Data
最新发布
01-18
### Payload vs Form Data in HTTP Requests In the context of HTTP requests, both **payload** and **form data** refer to different ways of sending information from a client to a server. Understanding how each works helps developers choose the appropriate method based on their needs. #### Definition and Usage A payload generally refers to any data sent within an HTTP request body that is intended for processing by the recipient service or application. This term encompasses various formats including JSON, XML, plain text, binary files, etc., depending upon what type of content-type header has been specified[^1]. Form data specifically pertains to key-value pairs transmitted via POST methods using `application/x-www-form-urlencoded` or `multipart/form-data`. The former encodes characters as URL parameters while multipart form data allows uploading multiple pieces of data such as file attachments alongside textual inputs without being constrained by size limits imposed by URLs[^2]. #### Differences Between Payload and Form Data The primary distinction lies in encoding mechanisms used during transmission: - With payloads, applications have greater flexibility regarding format choice since they aren't restricted solely to simple name-value collections. - Conversely, traditional web forms typically utilize either urlencoded strings (suitable only for small amounts of non-binary info) or multi-part entities designed primarily around submitting documents along with metadata describing them like filenames & MIME types[^3]. For example, consider this Python code snippet demonstrating how one might construct these two kinds of submissions programmatically: ```python import requests # Example of sending JSON payload json_payload = {"key": "value"} response_json = requests.post('https://example.com/api', json=json_payload) # Example of posting form-encoded data form_data = {'field': 'data'} files = {'file_field': open('document.pdf', 'rb')} response_form = requests.post('https://example.com/upload', data=form_data, files=files) ``` --related questions-- 1. What are some common use cases where you would prefer using a JSON payload over form data? 2. How does setting Content-Type affect handling of incoming requests at the server side? 3. Can you explain under which circumstances should multipart/form-data be utilized instead of application/x-www-form-urlencoded? 4. Are there performance implications associated with choosing between these submission styles? 5. In RESTful API design principles, do recommendations exist concerning selection among available media types?
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

modem协议笔记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值