CN101567749B - 一种下行数据传输方法和装置 - Google Patents
一种下行数据传输方法和装置 Download PDFInfo
- Publication number
- CN101567749B CN101567749B CN 200810104392 CN200810104392A CN101567749B CN 101567749 B CN101567749 B CN 101567749B CN 200810104392 CN200810104392 CN 200810104392 CN 200810104392 A CN200810104392 A CN 200810104392A CN 101567749 B CN101567749 B CN 101567749B
- Authority
- CN
- China
- Prior art keywords
- memory
- exented
- memory size
- support
- exented memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 289
- 230000005540 biological transmission Effects 0.000 title claims abstract description 62
- 230000015654 memory Effects 0.000 claims abstract description 595
- 230000008569 process Effects 0.000 claims description 230
- 238000012546 transfer Methods 0.000 claims description 28
- 230000009885 systemic effect Effects 0.000 claims description 15
- 238000012545 processing Methods 0.000 claims description 12
- 239000000872 buffer Substances 0.000 claims description 8
- 101100465000 Mus musculus Prag1 gene Proteins 0.000 claims description 7
- 238000004364 calculation method Methods 0.000 claims description 5
- 238000013459 approach Methods 0.000 abstract description 4
- 230000008901 benefit Effects 0.000 abstract description 2
- 230000002708 enhancing effect Effects 0.000 abstract 1
- 238000007781 pre-processing Methods 0.000 abstract 1
- 238000004080 punching Methods 0.000 description 8
- 230000011664 signaling Effects 0.000 description 8
- 238000013461 design Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000010276 construction Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000009897 systematic effect Effects 0.000 description 3
- 238000013500 data storage Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
Abstract
本发明公开了一种下行数据传输方法，终端向基站上报自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；基站根据上下行比例获得下行所支持的最大进程数N；基站根据所述终端等级、所述扩展内存指示以及所支持的最大进程数N，进行内存分配预操作，并进行下行传输。本发明还公开了一种用户终端和基站。通过本发明，基站能够有针对性的采取内存分配方式分配UE中的内存，从而避免有效速率匹配速率接近或超过1的情况，进而提高***传输的可靠性。
Description
技术领域
本发明涉及移动通信技术，特别涉及一种移动通信中的下行数据传输方法和装置。
背景技术
在长期演进(LTE)***的混合自动请求重传(HARQ)机制中，基站在将任一HARQ进程数据下发给用户终端(UE)时，基站分多次下发进程数据，每次下发该进程数据中的一部分，UE在第一次接收基站下发的一部分进程数据后，对接收数据进行解码，如果解码成功，则向基站反馈ACK信息，基站不再下发该进程的其他数据；如果解码失败，则将解码出的结果进行存储，并向基站反馈NACK信息，基站接收NACK信息后继续向UE下发该进程的下一部分进程数据，UE在接收到下一部分进程数据后将保存的上次解码结果进行合并后解码，并根据是否解码成功按照前述方式进行处理，如此往复，直到解码成功或接收到该进程的所有数据。
在上述LTE***中，基站使用母码码率1/3的速率匹配速率算法对HARQ进程的信息数据进行速率匹配，也就是说，对于N比特的信息数据，在进行速率匹配后，形成的数据传输块为3N比特，当解码失败时，需要存储的数据量也就是3N比特。可见，在1/3的速率匹配速率下，UE端设置的内存容量相对较大。
针对该问题，FDD***提出使用了有限缓存器速率匹配(LBRM，limitedbuffer rate matching)算法，即信息数据进行1/3速率匹配以后，再对信息数据和校验数据进行打孔，使得剩余的信息数据和校验数据总长度是以前的一半，得到的有效速率匹配速率为2/3，采用2/3的有效速率匹配速率编码对的***性能也可以保障。
其中打孔的原则是前提速率匹配后信息数据和校验数据组成的数据块的终点位置。例如，图1为全缓存器速率匹配示意图，其中，阴影部分表示信息数据，白色部分表示进行1/3速率匹配后加入的校验数据，图中的RV0表示第一次传输数据的起始点位置，RV1表示接收到NACK信息后第二次传输进程数据时的起始点位置...。图2为基于图1进行的LBRM算法打孔示意图，其中，将校验数据的后面一部分数据打孔删除，在进行传输时，即不再传输这部分数据，图中的RV0等与图1中的含义相同。这里需要说明的是，图2中进行的打孔并非按照2/3的速率匹配速率进行，而只是一个打孔的示意图。
在利用LBRM算法对进程数据打孔后，有效速率匹配速率为2/3，从而使得解码失败后每个HARQ进程在UE中的存储数据量就缩小了一半。对于FDD***8个进程，UE总的内存大小在设计时也可以减小一半，大大节约了成本。
在LTE***中，UE终端设计支持时分双工TDD和频分双工FDD的双模式。目前在UE终端设计时，TDD模式和FDD模式使用大小相同的内存器存储多个进程的数据。在***运行时，如果TDD模式和FDD模式支持相同的峰值速率传输，那么每个进程传输的数据块大小应相同。但是，由于TDD模式下，不同的上下行时隙比例对应不同的进程数，在某些上下行时隙比例下，其进程数高于8(例如9，10，12和15)，因此，如果要令TDD模式和FDD模式支持相同的峰值速率传输，按照FDD模式设计的LTE终端，则无法支持TDD模式下高于8个进程的状况。
面对这种情况，如果通过更多的打孔来压缩每个进程所占的内存，那么TDD模式使用LBRM算法压缩信息数据和校验数据时，相应的有效速率匹配速率对应9，10，12和15个进程分别为3/4，5/6，1和5/4，其中，后三种速率值明显接近或大于‘1’，将会导致***可靠性的严重下降，无法满足***性能要求。
发明内容
有鉴于此，本发明提供一种下行数据传输方法、以及相应的基站和用户终端，能够提高TDD模式下数据传输的可靠性。
为实现上述目的，本发明采用如下的技术方案：
一种下行数据传输方法，包括：
基站接收终端上报的自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；
基站根据上下行比例获得下行所支持的最大进程数N；
基站根据所述终端等级、所述扩展内存指示以及所支持的最大进程数N，进行内存分配预操作，并进行下行传输。
较佳地，所述基站接收终端上报的扩展内存指示为：所述终端利用1比特信息进行所述上报，所述1比特信息的两个状态，分别代表不支持扩展内存和支持扩展内存。
较佳地，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存所表示的内存大小与大于N0的四个下行进程数中的一个进程数对应，所述N0为所述基本内存大小对应的进程数。
较佳地，所述基站接收终端上报的扩展内存指示为：所述终端利用2比特信息进行所述上报，所述2比特信息的四个状态，分别代表不支持扩展内存，支持扩展内存大小A，支持扩展内存大小B，支持扩展内存大小C。
较佳地，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别与大于N0的四个下行进程数中的三个相对应，所述N0为所述基本内存大小对应的进程数。
较佳地，所述基站接收终端上报的扩展内存指示为：所述终端利用3比特信息进行所述上报，所述3比特信息的五个状态，分别代表不支持扩展内存，支持扩展内存大小A、支持扩展内存大小B，支持扩展内存大小C、支持扩展内存大小D。
较佳地，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存A、支持扩展内存B和支持扩展内存C所表示的内存大小分别与大于N0的四个下行进程数一一对应，所述N0为所述基本内存大小对应的进程数。
较佳地，该方法进一步包括：
预先将基本内存大小乘以任一扩展内存指示所对应的进程数再除以N0，将计算结果作为所述任一扩展内存指示所表示的内存大小。
较佳地，所述基站根据终端反馈的所述终端等级、所述扩展内存指示以及所支持的最大进程数N，进行内存分配预操作，并进行下行传输包括：
基站根据终端等级所对应的内存大小以及扩展内存指示所对应的内存大小，计算终端所支持的最大进程数M；
基站判断扩展内存指示所对应的内存大小是否满足最大进程数M的要求，若是，进行内存分配预操作1及相应的下行传输；否则，进行内存分配预操作2及相应的下行传输。
较佳地，该方法进一步包括：终端根据基站的内存分配预操作进行实际内存分配操作，并进行数据的处理操作。
较佳地，所述基站进行内存分配预操作1及相应的下行传输为：按照N或M进行等分UE中的内存，并按照分配后的内存进行相应的下行传输。
较佳地，所述在基站侧进行内存分配预操作2及相应的下行传输为：基站根据进程数N等分内存，降低调制编码方式进行下行传输；
或者，基站根据进程数N等分内存，在有效范围内增加LBRM的有效速率匹配速率，减小每次传输信息的长度进行下行传输。
较佳地，所述基站进行内存分配预操作2为及相应的下行传输：基站根据进程数M等分内存，根据进程数N进行下行数据的调度和传输；
所述终端根据基站的内存分配预操作进行实际内存分配操作，并进行数据的处理操作包括：终端根据进程数M等分内存，对于超出所述进程数M之外的、且传输错误的进程数据，直接抛弃，并向基站反馈NACK信息。
较佳地，所述基站进行内存分配预操作2及相应的下行传输为：基站根据进程数N等分内存，并按照分配后的内存进行相应的下行传输；
所述终端根据基站的内存分配预操作进行实际内存分配操作，并进行相关数据的存储操作包括：终端根据进程数N等分内存，对于超出内存大小的数据进行部分丢弃；任一进程多次重传数据合并时，对新到的所有数据和存储的数据进行部分合并。
较佳地，所述基站进行内存分配预操作2及相应的下行传输为：基站配置下行进程数目，根据该进程数等分内存，并将进程数目告知给终端，并按照分配后的内存进行相应的下行传输；
所述终端根据基站的内存分配预操作进行实际内存分配操作，并进行相关数据的存储操作为：终端接收基站下发的进程数目，根据该进程数目进行实际内存分配操作，并进行数据的处理操作。
一种用户终端，包括：终端等级上报单元，扩展内存指示上报单元、内存分配及处理单元；
所述终端等级上报单元，用于将自身的终端等级上报给基站；
所述扩展内存指示上报单元，用于将表示自身内存大小的扩展内存指示信息上报给基站；
所述内存分配及处理单元，用于根据基站下发的内存分配方式为每个进程分配内存并处理接收数据。
一种基站，包括：终端等级接收单元，扩展内存指示接收单元、最大进程数确定单元、内存预分配单元及数据调度传输单元，
所述终端等级接收单元，用于接收终端上报的终端等级，并发送给所述内存预分配及数据调度传输单元；
所述扩展内存指示接收单元，用于接收终端上报的扩展内存指示信息，并发送给所述内存预分配及数据调度传输单元；
所述最大进程数确定单元，用于确定当前上下行子帧比例所对应的最大进程数N；
所述内存预分配单元，用于根据终端反馈的所述终端等级、所述扩展内存指示以及所支持的最大进程数N，进行内存分配预操作；
所述数据调度传输单元，用于根据确定的每一个进程的内存大小进行数据调度和传输。
由上述本发明的技术方案可见，本发明中，基站接收UE上报的自身支持的终端等级以及用于终端内存大小的扩展内存指示，基站根据该终端内存大小进行具体的内存分配预操作和数据调度传输。这样，终端内存大小有多种，并通过UE上报自身支持的终端内存大小，基站能够有针对性的采取内存分配方式为进程分配UE中的内存，从而避免有效速率匹配速率接近或超过1的情况，进而提高***传输的可靠性。
附图说明
图1为全缓存器速率匹配示意图。
图2为基于图1进行的LBRM算法打孔示意图。
图3为本发明提供的下行数据传输的方法总体流程图。
图4为本发明提供的UE的总体结构图。
图5为本发明提供的基站的总体结构图。
图6为本发明实施例中下行数据传输的方法具体流程图。
具体实施方式
为使本发明的目的、技术手段和优点更加清楚明白，以下结合附图对本发明作进一步详细说明。
目前，根据传输块大小和有效速率匹配速率，标准定义了支持N0个进程时的UE终端缓存器大小，具体描述如下表1。其中UE类型表示UE支持的终端等级，对于不同的终端等级，N0个进程对应的基本内存大小不同。
表1UE类型的下行物理层参数值
| UE类型 | 最大传输块大小(bit) | 有效速率匹配速率 | 基本内存大小(bit) |
| 类型1 | [10040] | 1/3 | [242,880] |
| 类型2 | [50000] | 1/3 | [1,206,624] |
| 类型3 | [100000] | 2/3 | [1,206,624] |
| 类型4 | [150112] | 2/3 | [1,811,232] |
| 类型5 | [300064] | 2/3 | [3,620,256] |
本发明的基本思想为：设置UE可选的多种终端内存大小，UE向基站上报自身所支持的终端内存大小，基站根据接收的信息确定具体的内存分配和数据调度传输方式。
图3为本发明提供的HARQ进程数据传输方法的总体流程图。如图3所示，该流程包括：
步骤301，预先设置UE可选的内存大小，为UE确定所述内存大小中的任意一种。
本步骤中，设置多种终端内存大小，包括最大支持N0个进程的基本内存大小和最大支持大于N0个进程的扩展内存大小。其中，基本内存大小即如表1所示；扩展内存大小是本发明新增的终端可选的内存大小，通过扩展终端的缓存器大小，从而使其能够支持大于N0个进程的情况。具体扩展内存大小还可以有多种选择，分别支持不同的进程数。根据需要，可以将扩展内存大小定义为UE对应的总的内存大小，也可以将其定义为在基本内存基础上增加的内存大小。
通过上述设置，在进行LTE终端设计时，可以选择将UE设计为支持任意一种内存大小，也就是将UE的缓存器确定为任意一种内存大小。
步骤302，TDD模式下进行下行数据传输时，UE向基站上报自身支持的终端等级以及表示自身内存大小的扩展内存指示。
根据预先设定的扩展内存指示所表示的内存大小，将本UE的内存大小上报给基站，具体可以通过高层信令的方式通知基站。
步骤303，基站接收并确定UE所支持的终端内存大小，确定当前上下行子帧比例所对应的最大进程数。
基站一方面确定UE支持的终端内存大小，另一方面根据当前上下行子帧比例确定最大进程数。
步骤304，基站根据终端等级、扩展内存指示以及所支持的最大进程数N，进行内存分配预操作，并进行下行传输。
至此，本发明的传输HARQ进程数据的方法流程结束。
图4和图5分别为本发明提供的UE和基站的总体结构图，该UE和基站可以用于实施上述HARQ进程数据传输方法。
如图4所示，该UE包括：终端等级接收单元，扩展内存指示上报单元、内存分配及处理单元。其中，终端等级上报单元，用于将自身的终端等级上报给基站；扩展内存指示上报单元，用于将自身支持的终端内存大小上报给基站；内存分配及处理单元，用于根据基站下发的内存分配方式为进程分配内存并处理接收数据。
如图5所示，该基站包括：终端等级接收单元，扩展内存指示接收单元、最大进程数确定单元、内存预分配单元及数据调度传输单元。其中，所述终端等级接收单元，用于接收终端上报的终端等级，并发送给所述内存预分配及数据调度传输单元。扩展内存指示接收单元，用于接收终端上报的扩展内存指示信息，并发送给所述内存预分配及数据调度传输单元。最大进程数确定单元，用于确定当前上下行子帧比例所对应的最大进程数。内存预分配单元用于根据终端反馈的所述终端等级、所述扩展内存指示以及所支持的最大进程数N，进行内存分配预操作。数据调度传输单元，用于根据确定的每一个进程的内存大小进行数据调度和传输。
上述即为对本发明的总体概述，以下通过参照图6对本发明的具体实施方式进行详细说明。
步骤601，根据LBRM算法计算UE终端内存大小，设置终端内存类型，为UE确定所述内存大小中的任意一种。
本发明中设置表示多种终端内存大小的扩展内存指示，各种不同的扩展内存指示对应不同的进程数。其中，将现有的基本内存大小所对应的扩展内存指示设置为不支持扩展内存，其对应的进程数为N0；并引入对应大于N0个进程的其他不同进程数的扩展内存指示。具体大于N0进程的进程数可以为9、10、12或15，即对应目前TDD模式的进程数，当然，也可以选择其他大于N0的进程数。
本步骤中，需要针对大于N0的进程数计算各种扩展内存指示所表示的内存大小，具体可以根据LBRM算法进行计算，其中最大传输块大小保持与表1所示的相同，以使TDD模和FDD模式下，***可以达到相同的最大峰值速率；有效速率匹配速率为2/3，即保证内存适当减小时，打掉一定的数据而不影响***性能。
具体的，本发明中在大于N0的进程数中选择四种进程数，将该四种进程数对应的内存大小作为与该进程数对应的扩展内存指示所表示的内存大小，具体该进程数对应的内存大小的计算方式为：基本内存大小乘以对应的进程数再除以N0。以N0＝8，新增支持大于8个进程的9、10、12和15个进程为例，大于N0的进程数对应的所有可能的扩展内存指示包括：对应进程数为9的扩展内存大小a，该扩展内存大小a所表示的内存大小为，基本内存大小乘以9/8；对应进程数为10的扩展内存大小b，该扩展内存指示所表示的内存大小为，基本内存大小乘以5/4；对应进程数为12的扩展内存大小c，该扩展内存指示所表示的内存大小为，基本内存大小乘以4/3；对应进程数为15的扩展内存大小d，该扩展内存指示所表示的内存大小为，基本内存大小乘以15/8。具体的扩展内存指示参数如表2和表3所示。其中，表2的扩展内存大小代表的是实际内存大小与基本内存大小的差值；表3的扩展内存大小代表的是实际内存大小。
表2UE类型的下行物理层参数值
表3UE类型的下行物理层参数值
上述为所有可能被设置为扩展内存指示的四种扩展内存大小的参数设置。事实上，在进行本发明实施时，除表示基本内存大小的扩展内存指示外，其他扩展内存指示不一定包括所有上述四种，而根据需要只设定其中的一种或几种，则后续UE和基站只会针对设置的扩展内存指示进行操作。
在TDD模式下进行数据传输时，执行如下操作：
步骤602，UE将自身支持的终端等级和用于表示自身内存大小的扩展内存指示上报给基站。
对于终端等级上报的方式可以采用现有方式实现，这里就不再赘述。
对于扩展内存指示的上报，考虑不同的上报信息开销，本发明给出3种信息上报方案，分别为利用1比特信息上报、利用2比特信息上报和利用3比特信息上报。
当采用不同的长度的信息上报扩展内存指示时，其对应的在步骤601中设置的内存大小也不相同。
以下具体介绍三种上报方式：
(一)利用1比特信息上报
当采用1比特信息上报扩展内存指示时，步骤601中设置两种可选内存大小以及表示该两种内存大小的两种扩展内存指示。这两种扩展内存指示分别为不支持扩展内存和支持扩展内存，其中，不支持扩展内存大小所表示的内存大小为基本内存大小，支持扩展内存可以根据需要对应大于N0的任意进程数Nx，并根据该进程数计算所表示的内存大小。
在***设计初期，即会确定两种UE的可选内存大小，UE在上报扩展内存指示时，利用1比特信息的两种取值分别代表不支持扩展内存和支持扩展内存。例如，***设计初期，确定对于任一类型的UE，可以不支持扩展内存，或者支持扩展内存，基站在接收到UE上报的扩展内存指示后，根据扩展内存指示的取值确定UE是否支持扩展内存。
具体的1比特扩展内存指示的取值分配可以是：上报1bit信息‘1’，表示UE不支持扩展内存，其表示的内存大小为基本内存大小；反之，上报1bit信息‘0’，表示UE支持扩展内存，其表示的内存大小为支持Nx个进程的内存大小。
在FDD***中，使用1bit的信令指示专用导频信号(DRS)，而TDD***中这1bit并未使用，因此可以设计UE利用该1bit资源作为内存信息上报基站，从而并未对***的控制信令增加额外的开销，当然也可以额外设置1比特的高层信令作为内存信息。
本上报方式中，对信令开销影响小或没有影响，但是可供选择的终端内存类型较少。
(二)利用2比特信息上报
当采用2比特信息上报扩展内存指示时，步骤601中设置四种UE可选的内存大小以及表示该四种内存大小的四种扩展内存指示。这四种扩展内存指示分别为：不支持扩展内存、支持扩展内存大小A、支持扩展内存大小B、支持扩展内存大小C。其中，不支持扩展内存所表示的内存大小为基本内存大小，对应进程数N0；支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别对应大于N0的四种进程数中的三种N1、N2、N3。
与前述(一)中相同，在***设计初期，即会确定四种UE可选的内存大小，UE在上报扩展内存指示时，利用2比特信息的四种取值分别代表不支持扩展内存、支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C。
仍以N0＝8，大于N0的四种进程数分别为9、10、12和15为例，四种扩展内存指示与2比特信息的四种取值的对应关系可以如表4所示。
表4 2比特内存信息对应UE支持的终端内存类型方案
表4示出了A、B、C三种不同的扩展内存指示的设置方式，其中，所选择的大于N0的三个进程数不同，因此，对于上述三种选择，支持扩展内存大小A、支持扩展内存大小B、支持扩展内存大小C所实际对应的进程数也不相同。另外，在本上报方式中，可以利用增设的高层信令携带扩展内存指示上报给基站。相比于第一种上报方式，信令开销增大，但是UE可以选择支持的内存大小增多了。
(三)利用3比特信息上报
当采用3比特信息上报扩展内存指示时，步骤601中设置五种UE可选的内存大小以及表示该四种内存大小的四种扩展内存指示。这五种扩展内存指示分别为：不支持扩展内存、支持扩展内存大小A、支持扩展内存大小B、支持扩展内存大小C、支持扩展内存大小D。其中，不支持扩展内存所表示的内存大小为基本内存大小，对应进程数N0；支持扩展内存大小A、支持扩展内存大小B、支持扩展内存大小C和支持扩展内存大小D所表示的内存大小分别与大于N0的四种进程数N1、N2、N3、N4一一对应。
仍以N0＝8，大于N0的四种进程数分别为9、10、12和15为例，在设置五种扩展内存指示与3比特信息的五种取值的对应关系时，可以如下进行设置：在上报扩展内存指示时，3比特内存信息中的首比特信息表示UE终端内存是否支持基站所有时隙比例传输所需的内存大小，也就是表示能否支持15个进程。当首比特表示不支持基站所有时隙比例传输所需的内存大小时，后2比特信息表示不支持扩展内存、对应9个进程的扩展内存指示、对应10个进程的扩展内存指示或对应12个进程的扩展内存指示。例如，如果支持基站所有时隙比例传输所需的内存大小，首比特上报1bit信息‘1’，全部3bits信息可以表示为‘100’；反之，如果不支持，首比特上报1bit信息‘0’；当首个比特信息为‘0’时，利用后2比特信息‘01’，‘10’，‘11’和‘00’分别表示对应12个进程的扩展内存指示、对应10个进程的扩展内存指示、对应9个进程的扩展内存指示或不支持扩展内存，具体3bits内存信息的取值与扩展内存指示的对应可以如表5。
表5 3比特内存信息对应含义
| 内存信息 | 表示含义 |
| 100 | UE内存支持基站时隙比例配置所需的内存大小 |
| 001 | UE内存不支持基站时隙比例配置所需的内存大小，对应12个进程的扩展内存指示 |
| 010 | UE内存不支持基站时隙比例配置所需的内存大小，对应10个进程的扩展内存指示 |
| 011 | UE内存不支持基站时隙比例配置所需的内存大小，对应9个进程的扩展内存指示 |
| 000 | UE内存不支持基站时隙比例配置所需的内存大小，不支持扩展内存 |
在本上报方式中，可以利用增设的高层信令携带内存信息上报给基站。相比于前两种上报方式，信令开销最大，但是UE可以选择的内存大小最多。
步骤603，基站接收并确定UE的扩展内存指示，并确定当前上下行时隙比例所对应的最大进程数。
本步骤中，根据UE与基站预先约定好的扩展内存指示上报方式，基站解析UE上报的内存信息，并确定UE支持的内存大小。具体确定方式即为与步骤602中上报终端内存类型的方式相对应，这里就不再赘述。
进一步，基站根据上下行时隙比例，获得当前下行传输支持的最大进程数N。
具体的上下行时隙比例与进程数的关系与现有的规定相同，具体如表6所示。
表6上下行时隙比例与最大进程数的对应关系
步骤604，基站判断UE的扩展内存指示是否满足所述最大进程数的要求，若是，执行步骤605，否则执行步骤606。
如前所述，不同的终端内存大小对应支持的不同进程数，因此根据终端等级所对应的内存大小以及扩展内存指示所对应的内存大小，能够计算终端所支持的最大进程数M，也即该扩展内存指示对应的进程数。若UE的内存大小所对应的进程数M大于等于所述最大进程数，则确定满足最大进程数的要求，否则，确定不满足最大进程数的要求。
步骤605，进行预先设定的内存分配预操作1，并执行相应的数据调度和传输，再执行步骤607。
为方便起见，这里将本步骤的基站操作和对应步骤607中UE的操作一并介绍。其中，假定预先设定的内存分配预操作1可以为：按照N进行等分UE中的内存，然后进行数据调度和传输，UE也相应的按照N等分内存进行数据处理和存储；或者，预先设定的内存分配预操作1也可以为：按照M进行等分UE中的内存，然后进行数据调度和传输，UE也相应的按照M等分内存进行数据处理和存储。
步骤606，进行预先设定的内存分配预操作2、并执行相应的数据调度和传输；再执行步骤607。
为方便起见，这里将本步骤的基站操作和对应步骤607中UE的操作一并介绍，具体预先设定的方式可以考虑以下几种方案：
a、基站动态分配各进程在UE中的内存，即根据UE终端内存能够支持的进程数，不平均分配每个进程内存大小，根据动态分配结果进行数据调度和传输；具体的，可以根据服务类型的不同，为不同服务类型的进程分配不等的内存，例如，为语音数据分配较小的内存，为视频数据分配较大的内存。UE根据基站下发的动态内存分配方式进行内存分配，并按照内存分配进行数据接收和处理，或者及时清空传输成功的进程内的数据信息，例如，在某进程数据传输成功后，清空该进程所占用的内存，分配给其他的进程。
b、限制部分或全部进程的传输峰值速率，基站根据进程数N等分内存，降低调制编码方式，进行数据调度和传输；例如，将传输峰值速率限制在一个预设的阈值附近，不以最高调制编码方式传输，这样可以相应降低每个进程所占用的存储器大小，因而使有限的内存资源支持更多的进程数。UE按照基站下发的进程数等分内存，并进行相应的数据接收和处理。
c、根据进程数N等分内存，在有效的LBRM速率匹配速率范围内，提高LBRM速率匹配速率，进行数据调度和传输；例如，在LBRM速率匹配速率≤3/4的范围内，尽量提高LBRM速率匹配速率，即对每个进程传输的数据块打掉更多的比特，以减少每个进程的数据大小，使UE终端内存有足够的空间可以存储更多进程数的数据信息。UE按照基站下发的进程数等分内存，并按照基站下发的LBRM速率匹配速率进行解码。
d、按照M等分UE中的内存，并按照最大进程数N进行数据调度和传输；UE按照基站下发的进程数等分内存，对于超出所述下发的进程数之外的、且传输错误的进程数据，直接抛弃，并向基站反馈NACK信息；例如，UE支持的终端内存类型对应的进程数M为8，而根据上下行时隙比例确定的最大进程数N为10，则基站按照8个进程等分UE中的内存，并按照最大进程数10进行调度，在UE中，对于超过8个之外的后2个进程，若解码失败，则直接抛弃该进程的数据并反馈NACK信息。此种方式下，对于前M个进程能够很好的保证数据传输的可靠性要求，但是对于后N-M个进程可能导致数据传输性能比较差。
e、基站按照最大进程数N等分UE中的内存，UE根据每个进程的内存大小存储数据，对于超出内存大小的数据直接丢弃，在将任一进程多次重传数据合并时，根据内存大小进行部分合并。例如，UE支持的终端内存类型对应的进程数M为9，而根据上下行时隙比例确定的最大进程数N为10，则基站按照最大进程数10等分内存，并按照最大进程数10进行调度和数据传输，终端根据每个进程的内存大小进行存储，丢弃每个进程中后面一部分数据，在多次重传数据的合并时根据内存大小进行部分合并。此种方式与方式d相比，所有N个进程的数据传输可靠性比较平均。
f、基站基站配置下行进程数目，根据该进程数等分内存，将进程数目告知给终端，并按照该配置的下行进程数目进行数据调度和传输，UE按照基站下发的进程数等分内存，并进行数据接收和处理。
步骤607，终端根据预设的内存分配预操作进行实际内存分配操作，并进行数据的存储操作。
具体的接收和处理方式在前述步骤605和606中均以介绍，这里就不再赘述。
至此，本发明的方法流程结束。上述具体的方法流程可以在图4和图5所示的用户终端和基站中实施。
应用本发明，为UE和基站提供了多种可选的终端内存大小，UE使用很少的信息比特指示UE支持的终端内存大小，基站可以及时根据UE上报的扩展内存指示确定UE支持的内存大小，改变相应的UE内存分配方案和传输方式，从而避免有效速率匹配速率接近或超过1的情况，进而提高***传输的可靠性。
以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (32)
1.一种下行数据传输方法，其特征在于，该方法包括：
基站接收终端上报的自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；
基站根据上下行比例获得下行所支持的最大进程数N；
基站根据终端等级所对应的基本内存大小以及扩展内存指示所对应的内存大小，计算终端所支持的最大进程数M；
基站判断扩展内存指示所对应的内存大小是否满足最大进程数N的要求，若是，按照N或M进行等分UE中的内存，并按照分配后的内存进行相应的下行传输；
否则，基站根据进程数N等分内存，降低调制编码方式进行下行传输；或者，基站根据进程数N等分内存，在有效范围内增加有限缓存器速率匹配LBRM的有效速率匹配速率，减小每次传输信息的长度进行下行传输。
2.根据权利要求1所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用1比特信息进行所述上报，所述1比特信息的两个状态，分别代表不支持扩展内存和支持扩展内存。
3.根据权利要求2所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存所表示的内存大小与大于N0的四个下行进程数中的一个进程数对应，所述N0为所述基本内存大小对应的进程数。
4.根据权利要求1所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用2比特信息进行所述上报，所述2比特信息的四个状态，分别代表不支持扩展内存，支持扩展内存大小A，支持扩展内存大小B，支持扩展内存大小C。
5.根据权利要求4所示的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别与大于N0的四个下行进程数中的三个相对应，所述N0为所述基本内存大小对应的进程数。
6.根据权利要求1所述的方法，其特征在于，
所述基站接收终端上报的扩展内存指示为：所述终端利用3比特信息进行所述上报，所述3比特信息的五个状态，分别代表不支持扩展内存，支持扩展内存大小A、支持扩展内存大小B，支持扩展内存大小C、支持扩展内存大小D。
7.根据权利要求6所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存A、支持扩展内存B、支持扩展内存C和支持扩展内存D所表示的内存大小分别与大于N0的四种下行进程数一一对应，所述N0为所述基本内存大小对应的进程数。
8.根据权利要求3、5或7所述的方法，其特征在于，该方法进一步包括：
预先将基本内存大小乘以任一扩展内存指示所对应的进程数再除以N0，将计算结果作为所述任一扩展内存指示所表示的内存大小。
9.一种下行数据传输方法，其特征在于，该方法包括：
基站接收终端上报的自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；
基站根据上下行比例获得下行所支持的最大进程数N；
基站根据终端等级所对应的基本内存大小以及扩展内存指示所对应的内存大小，计算终端所支持的最大进程数M；
基站判断扩展内存指示所对应的内存大小是否满足最大进程数N的要求，若是，按照N或M进行等分UE中的内存，并按照分配后的内存进行相应的下行传输；
否则，基站根据进程数M等分内存，根据进程数N进行下行数据的调度和传输；终端根据进程数M等分内存，对于超出所述进程数M之外的、且传输错误的进程数据，直接抛弃，并向基站反馈NACK信息。
10.根据权利要求9所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用1比特信息进行所述上报，所述1比特信息的两个状态，分别代表不支持扩展内存和支持扩展内存。
11.根据权利要求10所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存所表示的内存大小与大于N0的四个下行进程数中的一个进程数对应，所述N0为所述基本内存大小对应的进程数。
12.根据权利要求9所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用2比特信息进行所述上报，所述2比特信息的四个状态，分别代表不支持扩展内存，支持扩展内存大小A，支持扩展内存大小B，支持扩展内存大小C。
13.根据权利要求12所示的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别与大于N0的四个下行进程数中的三个相对应，所述N0为所述基本内存大小对应的进程数。
14.根据权利要求9所述的方法，其特征在于，
所述基站接收终端上报的扩展内存指示为：所述终端利用3比特信息进行所述上报，所述3比特信息的五个状态，分别代表不支持扩展内存，支持扩展内存大小A、支持扩展内存大小B，支持扩展内存大小C、支持扩展内存大小D。
15.根据权利要求14所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存A、支持扩展内存B、支持扩展内存C和支持扩展内存D所表示的内存大小分别与大于N0的四种下行进程数一一对应，所述N0为所述基本内存大小对应的进程数。
16.根据权利要求11、13或15所述的方法，其特征在于，该方法进一步包括：
预先将基本内存大小乘以任一扩展内存指示所对应的进程数再除以N0，将计算结果作为所述任一扩展内存指示所表示的内存大小。
17.一种下行数据传输方法，其特征在于，该方法包括：
基站接收终端上报的自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；
基站根据上下行比例获得下行所支持的最大进程数N；
基站根据终端等级所对应的基本内存大小以及扩展内存指示所对应的内存大小，计算终端所支持的最大进程数M；
基站判断扩展内存指示所对应的内存大小是否满足最大进程数N的要求，若是，按照N或M进行等分UE中的内存，并按照分配后的内存进行相应的下行传输；
否则，基站根据进程数N等分内存，并按照分配后的内存进行相应的下行传输；终端根据进程数N等分内存，对于超出内存大小的数据进行部分丢弃；任一进程多次重传数据合并时，对新到的所有数据和存储的数据进行部分合并。
18.根据权利要求17所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用1比特信息进行所述上报，所述1比特信息的两个状态，分别代表不支持扩展内存和支持扩展内存。
19.根据权利要求18所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存所表示的内存大小与大于N0的四个下行进程数中的一个进程数对应，所述N0为所述基本内存大小对应的进程数。
20.根据权利要求17所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用2比特信息进行所述上报，所述2比特信息的四个状态，分别代表不支持扩展内存，支持扩展内存大小A，支持扩展内存大小B，支持扩展内存大小C。
21.根据权利要求20所示的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别与大于N0的四个下行进程数中的三个相对应，所述N0为所述基本内存大小对应的进程数。
22.根据权利要求17所述的方法，其特征在于，
所述基站接收终端上报的扩展内存指示为：所述终端利用3比特信息进行所述上报，所述3比特信息的五个状态，分别代表不支持扩展内存，支持扩展内存大小A、支持扩展内存大小B，支持扩展内存大小C、支持扩展内存大小D。
23.根据权利要求22所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存A、支持扩展内存B、支持扩展内存C和支持扩展内存D所表示的内存大小分别与大于N0的四种下行进程数一一对应，所述N0为所述基本内存大小对应的进程数。
24.根据权利要求19、21或23所述的方法，其特征在于，该方法进一步包括：
预先将基本内存大小乘以任一扩展内存指示所对应的进程数再除以N0，将计算结果作为所述任一扩展内存指示所表示的内存大小。
25.一种下行数据传输方法，其特征在于，该方法包括：
基站接收终端上报的自身支持的终端等级以及用于表示终端内存大小的扩展内存指示；
基站根据上下行比例获得下行所支持的最大进程数N；
基站根据终端等级所对应的基本内存大小以及扩展内存指示所对应的内存大小，计算终端所支持的最大进程数M；
基站判断扩展内存指示所对应的内存大小是否满足最大进程数N的要求，若是，按照N或M进行等分UE中的内存，并按照分配后的内存进行相应的下行传输；
否则，基站配置下行进程数目，根据该进程数等分内存，并将进程数目告知给终端，并按照分配后的内存进行相应的下行传输；终端接收基站下发的进程数目，按照基站下发的进程数等分内存，并进行数据的处理操作。
26.根据权利要求25所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用1比特信息进行所述上报，所述1比特信息的两个状态，分别代表不支持扩展内存和支持扩展内存。
27.根据权利要求26所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存所表示的内存大小与大于N0的四个下行进程数中的一个进程数对应，所述N0为所述基本内存大小对应的进程数。
28.根据权利要求25所述的方法，其特征在于，所述基站接收终端上报的扩展内存指示为：所述终端利用2比特信息进行所述上报，所述2比特信息的四个状态，分别代表不支持扩展内存，支持扩展内存大小A，支持扩展内存大小B，支持扩展内存大小C。
29.根据权利要求27所示的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存大小A、支持扩展内存大小B和支持扩展内存大小C所表示的内存大小分别与大于N0的四个下行进程数中的三个相对应，所述N0为所述基本内存大小对应的进程数。
30.根据权利要求25所述的方法，其特征在于，
所述基站接收终端上报的扩展内存指示为：所述终端利用3比特信息进行所述上报，所述3比特信息的五个状态，分别代表不支持扩展内存，支持扩展内存大小A、支持扩展内存大小B，支持扩展内存大小C、支持扩展内存大小D。
31.根据权利要求30所述的方法，其特征在于，所述不支持扩展内存所表示的内存大小为***预设的基本内存大小；
所述支持扩展内存A、支持扩展内存B、支持扩展内存C和支持扩展内存D所表示的内存大小分别与大于N0的四种下行进程数一一对应，所述N0为所述基本内存大小对应的进程数。
32.根据权利要求27、29或31所述的方法，其特征在于，该方法进一步包括：
预先将基本内存大小乘以任一扩展内存指示所对应的进程数再除以N0，将计算结果作为所述任一扩展内存指示所表示的内存大小。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200810104392 CN101567749B (zh) | 2008-04-22 | 2008-04-22 | 一种下行数据传输方法和装置 |
| PCT/CN2009/071408 WO2009129742A1 (zh) | 2008-04-22 | 2009-04-22 | 一种下行数据传输方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 200810104392 CN101567749B (zh) | 2008-04-22 | 2008-04-22 | 一种下行数据传输方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101567749A CN101567749A (zh) | 2009-10-28 |
| CN101567749B true CN101567749B (zh) | 2013-04-03 |
Family
ID=41216437
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 200810104392 Active CN101567749B (zh) | 2008-04-22 | 2008-04-22 | 一种下行数据传输方法和装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101567749B (zh) |
| WO (1) | WO2009129742A1 (zh) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102348237B (zh) * | 2011-10-28 | 2014-07-16 | 重庆邮电大学 | 一种宽带无线通信***中的数据排队方法 |
| CN106301704B (zh) * | 2015-05-26 | 2019-08-06 | 苏州简约纳电子有限公司 | Harq数据的缓存方法 |
| US11871381B2 (en) | 2018-11-16 | 2024-01-09 | Beijing Xiaomi Mobile Software Co., Ltd. | Data transmission method and apparatus |
| CN111078372B (zh) * | 2019-12-20 | 2023-08-08 | 北京思特奇信息技术股份有限公司 | 一种自动化进程管理方法及*** |
| CN111949492B (zh) * | 2020-08-20 | 2023-01-06 | 深圳市锐尔觅移动通信有限公司 | ***资源获取方法、装置及终端设备 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1689261A (zh) * | 2002-08-13 | 2005-10-26 | 松下电器产业株式会社 | 用于多个混合自动重复请求进程的进程配置的方法 |
| CN1764100A (zh) * | 2005-11-16 | 2006-04-26 | 中兴通讯股份有限公司 | 一种多频点小区中混合自动重传请求的实现方法 |
| CN1972177A (zh) * | 2006-11-29 | 2007-05-30 | 北京邮电大学 | 基于终端反馈的联合混合自动请求重传和调度算法的方法 |
| CN101053178A (zh) * | 2004-11-03 | 2007-10-10 | 三星电子株式会社 | 在宽带无线接入通信***中用于发射/接收混合自动重发请求缓冲器能力信息的***和方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4788436B2 (ja) * | 2006-03-29 | 2011-10-05 | 日本電気株式会社 | 無線リソース割り当て方法及びそれを用いる無線リソース割り当て装置並びに基地局 |
-
2008
- 2008-04-22 CN CN 200810104392 patent/CN101567749B/zh active Active
-
2009
- 2009-04-22 WO PCT/CN2009/071408 patent/WO2009129742A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1689261A (zh) * | 2002-08-13 | 2005-10-26 | 松下电器产业株式会社 | 用于多个混合自动重复请求进程的进程配置的方法 |
| CN101053178A (zh) * | 2004-11-03 | 2007-10-10 | 三星电子株式会社 | 在宽带无线接入通信***中用于发射/接收混合自动重发请求缓冲器能力信息的***和方法 |
| CN1764100A (zh) * | 2005-11-16 | 2006-04-26 | 中兴通讯股份有限公司 | 一种多频点小区中混合自动重传请求的实现方法 |
| CN1972177A (zh) * | 2006-11-29 | 2007-05-30 | 北京邮电大学 | 基于终端反馈的联合混合自动请求重传和调度算法的方法 |
Non-Patent Citations (2)
| Title |
|---|
| 3GPP.Evolved Universal Terrestrial Radio Access (E-UTRA) User Equipment (UE) radio access capabilities (Release 8).《3GPP TS 36.306 V8.1.0》.2008, * |
| Huawei et al.Way forward for TDD HARQ process.《TSG-RAN WG1 #52 R1-081124》.2008, * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101567749A (zh) | 2009-10-28 |
| WO2009129742A1 (zh) | 2009-10-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3419370B1 (en) | Method and device scheduling and allocating resource | |
| CN102017507B (zh) | 无线移动通信***中用于控制混合自动重发请求操作的装置和方法 | |
| CN102291768B (zh) | 为用户分配应答信道的方法、装置和*** | |
| CN102104962B (zh) | 多天线场景下的上行控制信道资源的配置方法和设备 | |
| CN101567749B (zh) | 一种下行数据传输方法和装置 | |
| CN103036660B (zh) | 一种反馈数据接收状况的方法 | |
| CN103428836B (zh) | 基于harq的数据传输方法、设备和*** | |
| CN101536584B (zh) | 在数据信道中向用户设备提供资源分配信息 | |
| CN102265695B (zh) | 一种调度方法及设备、控制信息的处理方法及设备 | |
| CN102077627B (zh) | 一种上行信号的处理方法、基站和用户终端 | |
| CN104202135A (zh) | 移动站与基站之间的连接处理方法、移动站和基站 | |
| JP2003143108A (ja) | 高速データパケット接続通信システムにおいて使用者データに割り当てられる直交コード情報を送受信する方法 | |
| CN102196495A (zh) | 下行数据传输方法、***和设备 | |
| CN103036657B (zh) | 一种数据传输方法和装置 | |
| CN102769507A (zh) | 一种在物理上行共享信道上传输确认或否认信息的方法 | |
| CN103812620A (zh) | 确定用于harq的应答信息在pucch中位置的方法 | |
| CN101499876A (zh) | 无线链路中自适应的进行crc校验的方法和装置 | |
| CN102307082A (zh) | 一种上行控制信令的传输方法及装置 | |
| CN102347825A (zh) | 一种传输反馈信息的方法、***和设备 | |
| CN109716699B (zh) | 用于混合自动重复请求过程的方法、网络设备和终端设备 | |
| CN102255708A (zh) | 一种反馈信息的传输方法及装置 | |
| CN101572661B (zh) | 基于时分双工模式的数据缓存方法、装置和*** | |
| CN101132597B (zh) | 资源分配方法、资源分配***、资源分配实体以及移动台 | |
| CN112769527B (zh) | 基于码块组的harq-ack反馈方法、装置及终端 | |
| CN102238735A (zh) | 可用软信道比特最大值的分配方法及*** |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: INST OF TELECOMMUNICATION SCIENCE AND TECHNOLGOY Free format text: FORMER OWNER: DATANG MOBILE COMMUNICATION EQUIPMENT CO., LTD. Effective date: 20110621 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 100083 NO. 29, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING TO: 100191 NO. 40, XUEYUAN ROAD, HAIDIAN DISTRICT, BEIJING |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20110621 Address after: 100191 Haidian District, Xueyuan Road, No. 40, Applicant after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY Address before: 100083 Haidian District, Xueyuan Road, No. 29, Applicant before: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CP01 | Change in the name or title of a patent holder | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee after: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20210615 Address after: 100085 1st floor, building 1, yard 5, Shangdi East Road, Haidian District, Beijing Patentee after: DATANG MOBILE COMMUNICATIONS EQUIPMENT Co.,Ltd. Address before: 100191 No. 40, Haidian District, Beijing, Xueyuan Road Patentee before: CHINA ACADEMY OF TELECOMMUNICATIONS TECHNOLOGY |